[jira] [Updated] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino updated PROTON-154:
-
Component/s: proton-c
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch, PROTON-154-test.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
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
[jira] [Commented] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505388#comment-13505388
]
Hiram Chirino commented on PROTON-154:
--
Python test case also verifies that this bug exists on the proton-c impl.
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch, PROTON-154-test.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505408#comment-13505408 ] Gordon Sim commented on PROTON-160: --- I greatly prefer option (3) as outlined at the end of comment #1(https://issues.apache.org/jira/browse/PROTON-160?focusedCommentId=13505199), i.e. having some way to configure a messenger to handle addresses (falling back to DNS based resolution if no rules exist/apply). Per-message addresses should ideally be logical with a flexible mapping to the physical addresses over which they should then be transferred. Option 3 seems the safest and neatest solution. I find option 1 confusing as well as I think being to tied to a particular pattern of use. I thinks URLs are actually a less than ideal choice for the address syntax as they confuse the notions of (hierarchical) domain scoped logical naming with 'connection strings', and adding in various options and parameters is I think the thin end of the wedge that will lead to muddiness. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505441#comment-13505441 ] Rafael H. Schloming commented on PROTON-160: I was assuming auto-redirect was part of what was being asked for in PROTON-164, but if not we can split that into a separate Jira. I do think it would be good if we could make the redirect happen transparently, e.g. treat it as part of the resolution process. Regarding the semantics being discussed, I'm unclear on the need for two messages with the same address to connect to different physical endpoints. What I'm leaning towards is some way to explicitly specify the TCP endpoint for a given address, but not necessarily on a per message basis, rather just a per address basis. This would omit both the problematic redirector scenario and maintain the semantic that for a given messenger, a given address will always resolve to a single connection. I like maintaining this property because I think it's a simpler model for users and in particular the security model here maps strongly to the one used by web browsers. You only need to look in one place (the to field) to figure out where a message is going, and your certificates are always validated against that. To draw an analogy to a web browser, if the to field is the URL, then I think the approach option (1) is taking is basically adding another input field to your web browser UI that lets you override DNS lookup whenever you type in a URL. This would let you type in the same URL twice, and get completely different results depending on the value typed into this other field. What I'm suggesting with option (3) is pretty much like overriding your /etc/hosts file so whenever a given URL appears, it resolves to something you control, but it will always resolve to the same thing until you go change your hosts file. I think these both have equivalent capabilities, but I feel like option (3) is simpler for the scenarios where I can imagine needing this kind of thing. As an aside, I think this aliasing thing would also give us a path towards more advanced configurations, e.g. imagine adding wildcard support and you have an easy way to instruct a messenger to direct all (or some subset) of messages through a single broker, e.g. alias * - my-broker, or alias *.foo - my-broker and alias *.bar - your-broker. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- 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
[jira] [Commented] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505485#comment-13505485
]
Rafael H. Schloming commented on PROTON-154:
I'm a little confused by the closed='false' in the detach. Are you trying to
reattach to an existing link endpoint?
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch, PROTON-154-test.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
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
[jira] [Assigned] (PROTON-169) Provide examples using web application frameworks
[ https://issues.apache.org/jira/browse/PROTON-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce reassigned PROTON-169: --- Assignee: Darryl L. Pierce Provide examples using web application frameworks - Key: PROTON-169 URL: https://issues.apache.org/jira/browse/PROTON-169 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Provide examples for writing messaging web apps using Ruby on Rails, Django and similar web technologies. -- 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
[jira] [Created] (PROTON-169) Provide examples using web application frameworks
Darryl L. Pierce created PROTON-169: --- Summary: Provide examples using web application frameworks Key: PROTON-169 URL: https://issues.apache.org/jira/browse/PROTON-169 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Darryl L. Pierce Provide examples for writing messaging web apps using Ruby on Rails, Django and similar web technologies. -- 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
[jira] [Commented] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505576#comment-13505576
]
Hiram Chirino commented on PROTON-154:
--
Hi Rafael, that's a different issue. See PROTON-156.
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch, PROTON-154-test.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
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
[jira] [Comment Edited] (PROTON-154) link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505576#comment-13505576
]
Hiram Chirino edited comment on PROTON-154 at 11/28/12 3:50 PM:
Hi Rafael, no, both endpoints are detaching. It's just the it always sets it to
false. but that's a different issue. See PROTON-156.
was (Author: chirino):
Hi Rafael, that's a different issue. See PROTON-156.
link attach, detach, attach sequence on single session does not result in a
new link for the 2nd attach
---
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Attachments: PROTON-154.patch, PROTON-154-test.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
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
[jira] [Created] (PROTON-170) generated pkg config file doesn't actually include paths if a different install location is used
Gordon Sim created PROTON-170: - Summary: generated pkg config file doesn't actually include paths if a different install location is used Key: PROTON-170 URL: https://issues.apache.org/jira/browse/PROTON-170 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make install will install a pkg config file that doesn't have the include and lib directories set. -- 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
[jira] [Assigned] (PROTON-170) generated pkg config file doesn't actually include paths if a different install location is used
[ https://issues.apache.org/jira/browse/PROTON-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim reassigned PROTON-170: - Assignee: Andrew Stitcher Andrew, requesting review from someone more expert in cmake and pkgconfig... generated pkg config file doesn't actually include paths if a different install location is used Key: PROTON-170 URL: https://issues.apache.org/jira/browse/PROTON-170 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.2 Reporter: Gordon Sim Assignee: Andrew Stitcher Attachments: PROTON-170.patch E.g. cmake -DCMAKE_INSTALL_PREFIX=/path/to/non-standard/install make install will install a pkg config file that doesn't have the include and lib directories set. -- 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505706#comment-13505706 ] Affan Dar commented on PROTON-160: -- I think the assumption behind option (1) was that adding a connection level setting (such as an alias) may not be appropriate for the level that the messenger API is operating it. Seems like that is not a big issue which is great. Connection aliasing is a good solution and will work for all scenarios (reconnect, redirect etc). It will also make the receive side more symmetric with the send side which is goodness. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- 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
[jira] [Commented] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505715#comment-13505715 ] Rafael H. Schloming commented on PROTON-160: Ok, thanks for wading through my ramblings. ;-) I'll take a crack at this and post again when I have something concrete. Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- 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
[jira] [Assigned] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming reassigned PROTON-160: -- Assignee: Rafael H. Schloming Allow open.hostname to be configured independently of network hostname -- Key: PROTON-160 URL: https://issues.apache.org/jira/browse/PROTON-160 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.1, 0.2 Reporter: David Ingham Assignee: Rafael H. Schloming In a scaled-out, multi-tenant broker environment, the host on which the container is running is often different from the host to which a client is establishing the tcp connection. The 'hostname' field in the connection open performative was added to support this scenario. Currently there's no way to control this from the Messenger API. Options include: (1) (preferred) add a new 'networkhost' field to Message to allow the network address to be specified. If provided, this information would be used when establishing the network connection and the data in the 'address' field would be used in the connection open hostname field. This is somewhat in line with the way that connection redirect (amqp:connection:redirect) is specified. (2) extend the syntax of address with query string to supply hostname, e.g., username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' would become the hostname used in the connection open frame. This is the approach used by the current Qpid AMQP 1.0 JMS client. -- 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: Unexpected behaviour in test ssl.py - possible bug?
Hi Phil, I think you've uncovered a bug - definitely raise a jira and assign it to me. Now that you mention it, I'm surprised that the original version of pump() worked properly - seems like it would risk discarding any output not consumed by the input handler.Your changes to pump() should be an improvement. -K - Original Message - Hi, We've been working on the Java SSL implementation and are seeing a test fail against proton-c but that works against proton-j. We're not sure if the problem is in proton-c, or in our modified test, and are hoping someone who knows about proton-c's SSL implementation can give a view on this before we raise a Jira. One of the scenarios we wanted to cover in our testing was the case where the Transport input method leaves left-overs, e.g. when you call server.input() with 100 bytes of input, but it only accepts 20, as indicated by its return value. For example, we expect this to happen if the preceding client.output() call is told to write to a buffer sized such that its output contains a trailing *fragment* of an SSL packet, which input() won't be able to decipher. We therefore modified the pump method in proton/tests/proton_tests/ssl.py to handle this case. In its loop, it now captures the bytes left over after calling input(), and prepends them to the input() invocation in the next iteration. The buffer size is now a parameter so individual tests can exercise the packet fragmenting behaviour described above. We made the following change: --- diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py index 8567b1b..237c3da 100644 --- a/tests/proton_tests/ssl.py +++ b/tests/proton_tests/ssl.py @@ -43,13 +43,32 @@ class SslTest(common.Test): self.t_client = None self.t_server = None -def _pump(self): +def _pump(self, buffer_size=1024): + +Make the transport send up to buffer_size bytes (this will be the AMQP +header and open frame) returning a buffer containing the bytes +sent. Transport is stateful so this will return 0 when it has +no more frames to send. +TODO this function is duplicated in sasl.py. Should be moved to a common place. + +out_client_leftover_by_server = +out_server_leftover_by_client = +i=0 while True: -out_client = self.t_client.output(1024) -out_server = self.t_server.output(1024) -if out_client: self.t_server.input(out_client) -if out_server: self.t_client.input(out_server) + +out_client = out_client_leftover_by_server + self.t_client.output(buffer_size) +out_server = out_server_leftover_by_client + self.t_server.output(buffer_size) + +if out_client: +number_server_consumed = self.t_server.input(out_client) +out_client_leftover_by_server = out_client[number_server_consumed:] # if it consumed everything then this is empty + +if out_server: +number_client_consumed = self.t_client.input(out_server) +out_server_leftover_by_client = out_server[number_client_consumed:] # if it consumed everything then this is empty + if not out_client and not out_server: break +i=i+1 def _testpath(self, file): Set the full path to the certificate,keyfile, etc. for the test. --- Several ssl tests now fail when run against proton-c, all with the same error. This surprised us because we hadn't started playing with the buffer size yet - we were still using the default of 1024. For example, test_server_authentication gives this output: proton_tests.ssl.SslTest.test_server_authentication .[0xa2ca208:0] ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac fail Error during test: Traceback (most recent call last): File ./tests/proton-test, line 331, in run phase() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in test_server_authentication self._pump() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump number_server_consumed = self.t_server.input(out_client) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141, in input return self._check(n) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115, in _check raise exc([%s]: %s % (err, pn_error_text(pn_transport_error(self._trans TransportException: [-2]: SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac Totals: 1 tests, 0 passed, 0 skipped, 0 ignored, 1 failed The first pump() call in this test works fine; the failure we see
[jira] [Created] (PROTON-171) after connection close, proton-c SSL decryption fails when left-over bytes passed to input()
Philip Harvey created PROTON-171:
Summary: after connection close, proton-c SSL decryption fails
when left-over bytes passed to input()
Key: PROTON-171
URL: https://issues.apache.org/jira/browse/PROTON-171
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Philip Harvey
We've been working on the Java SSL implementation and are seeing a test fail
against proton-c but that works against proton-j. We believe this is due to a
bug in proton-c.
One of the scenarios we wanted to cover in our testing was the case where the
Transport input method leaves left-overs, e.g. when you call server.input()
with 100 bytes of input, but it only accepts 20, as indicated by its return
value.
For example, we expect this to happen if the preceding client.output() call is
told to write to a buffer sized such that its output contains a trailing
*fragment* of an SSL packet, which input() won't be able to decipher.
We therefore modified the pump method in proton/tests/proton_tests/ssl.py to
handle this case. In its loop, it now captures the bytes left over after
calling input(), and prepends them to the input() invocation in the next
iteration. The buffer size is now a parameter so individual tests can exercise
the packet fragmenting behaviour described above.
We made the following change:
{noformat}
diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py
index 8567b1b..237c3da 100644
--- a/tests/proton_tests/ssl.py
+++ b/tests/proton_tests/ssl.py
@@ -43,13 +43,32 @@ class SslTest(common.Test):
self.t_client = None
self.t_server = None
-def _pump(self):
+def _pump(self, buffer_size=1024):
+
+Make the transport send up to buffer_size bytes (this will be the AMQP
+header and open frame) returning a buffer containing the bytes
+sent. Transport is stateful so this will return 0 when it has
+no more frames to send.
+TODO this function is duplicated in sasl.py. Should be moved to a
common place.
+
+out_client_leftover_by_server =
+out_server_leftover_by_client =
+i=0
while True:
-out_client = self.t_client.output(1024)
-out_server = self.t_server.output(1024)
-if out_client: self.t_server.input(out_client)
-if out_server: self.t_client.input(out_server)
+
+out_client = out_client_leftover_by_server +
self.t_client.output(buffer_size)
+out_server = out_server_leftover_by_client +
self.t_server.output(buffer_size)
+
+if out_client:
+number_server_consumed = self.t_server.input(out_client)
+out_client_leftover_by_server =
out_client[number_server_consumed:] # if it consumed everything then this is
empty
+
+if out_server:
+number_client_consumed = self.t_client.input(out_server)
+out_server_leftover_by_client =
out_server[number_client_consumed:] # if it consumed everything then this is
empty
+
if not out_client and not out_server: break
+i=i+1
def _testpath(self, file):
Set the full path to the certificate,keyfile, etc. for the test.
{noformat}
Several ssl tests now fail when run against proton-c, all with the same error.
This surprised us because we hadn't started playing with the buffer size yet -
we were still using the default of 1024.
For example, test_server_authentication gives this output:
{noformat}
proton_tests.ssl.SslTest.test_server_authentication
.[0xa2ca208:0]
ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac
fail
Error during test: Traceback (most recent call last):
File ./tests/proton-test, line 331, in run
phase()
File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in
test_server_authentication
self._pump()
File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump
number_server_consumed = self.t_server.input(out_client)
File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141,
in input
return self._check(n)
File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115,
in _check
raise exc([%s]: %s % (err,
pn_error_text(pn_transport_error(self._trans
TransportException: [-2]: SSL Failure: error:1408F119:SSL
routines:SSL3_GET_RECORD:decryption failed or bad record mac
Totals: 1 tests, 0 passed, 0 skipped, 0 ignored, 1 failed
{noformat}
The first pump() call in this test works fine; the failure we see is when it's
invoked again after closing the connection.
The problem is that the previous t_server.input call didn't accept *any* of the
bytes given to it. On the next
[jira] [Assigned] (PROTON-171) after connection close, proton-c SSL decryption fails when left-over bytes passed to input()
[ https://issues.apache.org/jira/browse/PROTON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey reassigned PROTON-171: Assignee: Ken Giusti after connection close, proton-c SSL decryption fails when left-over bytes passed to input() Key: PROTON-171 URL: https://issues.apache.org/jira/browse/PROTON-171 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Philip Harvey Assignee: Ken Giusti We've been working on the Java SSL implementation and are seeing a test fail against proton-c but that works against proton-j. We believe this is due to a bug in proton-c. One of the scenarios we wanted to cover in our testing was the case where the Transport input method leaves left-overs, e.g. when you call server.input() with 100 bytes of input, but it only accepts 20, as indicated by its return value. For example, we expect this to happen if the preceding client.output() call is told to write to a buffer sized such that its output contains a trailing *fragment* of an SSL packet, which input() won't be able to decipher. We therefore modified the pump method in proton/tests/proton_tests/ssl.py to handle this case. In its loop, it now captures the bytes left over after calling input(), and prepends them to the input() invocation in the next iteration. The buffer size is now a parameter so individual tests can exercise the packet fragmenting behaviour described above. We made the following change: --- diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py index 8567b1b..237c3da 100644 --- a/tests/proton_tests/ssl.py +++ b/tests/proton_tests/ssl.py @@ -43,13 +43,32 @@ class SslTest(common.Test): self.t_client = None self.t_server = None -def _pump(self): +def _pump(self, buffer_size=1024): + +Make the transport send up to buffer_size bytes (this will be the AMQP +header and open frame) returning a buffer containing the bytes +sent. Transport is stateful so this will return 0 when it has +no more frames to send. +TODO this function is duplicated in sasl.py. Should be moved to a common place. + +out_client_leftover_by_server = +out_server_leftover_by_client = +i=0 while True: -out_client = self.t_client.output(1024) -out_server = self.t_server.output(1024) -if out_client: self.t_server.input(out_client) -if out_server: self.t_client.input(out_server) + +out_client = out_client_leftover_by_server + self.t_client.output(buffer_size) +out_server = out_server_leftover_by_client + self.t_server.output(buffer_size) + +if out_client: +number_server_consumed = self.t_server.input(out_client) +out_client_leftover_by_server = out_client[number_server_consumed:] # if it consumed everything then this is empty + +if out_server: +number_client_consumed = self.t_client.input(out_server) +out_server_leftover_by_client = out_server[number_client_consumed:] # if it consumed everything then this is empty + if not out_client and not out_server: break +i=i+1 def _testpath(self, file): Set the full path to the certificate,keyfile, etc. for the test. --- Several ssl tests now fail when run against proton-c, all with the same error. This surprised us because we hadn't started playing with the buffer size yet - we were still using the default of 1024. For example, test_server_authentication gives this output: --- proton_tests.ssl.SslTest.test_server_authentication .[0xa2ca208:0] ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac fail Error during test: Traceback (most recent call last): File ./tests/proton-test, line 331, in run phase() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in test_server_authentication self._pump() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump number_server_consumed = self.t_server.input(out_client) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141, in input return self._check(n) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115, in _check raise exc([%s]: %s % (err, pn_error_text(pn_transport_error(self._trans TransportException: [-2]: SSL Failure: error:1408F119:SSL
Re: Unexpected behaviour in test ssl.py - possible bug?
Hi Ken, Thanks for looking into it. I've raised https://issues.apache.org/jira/browse/PROTON-171 and assigned it to you. Phil On Nov 28, 2012 6:19 PM, Ken Giusti kgiu...@redhat.com wrote: Hi Phil, I think you've uncovered a bug - definitely raise a jira and assign it to me. Now that you mention it, I'm surprised that the original version of pump() worked properly - seems like it would risk discarding any output not consumed by the input handler.Your changes to pump() should be an improvement. -K - Original Message - Hi, We've been working on the Java SSL implementation and are seeing a test fail against proton-c but that works against proton-j. We're not sure if the problem is in proton-c, or in our modified test, and are hoping someone who knows about proton-c's SSL implementation can give a view on this before we raise a Jira. One of the scenarios we wanted to cover in our testing was the case where the Transport input method leaves left-overs, e.g. when you call server.input() with 100 bytes of input, but it only accepts 20, as indicated by its return value. For example, we expect this to happen if the preceding client.output() call is told to write to a buffer sized such that its output contains a trailing *fragment* of an SSL packet, which input() won't be able to decipher. We therefore modified the pump method in proton/tests/proton_tests/ssl.py to handle this case. In its loop, it now captures the bytes left over after calling input(), and prepends them to the input() invocation in the next iteration. The buffer size is now a parameter so individual tests can exercise the packet fragmenting behaviour described above. We made the following change: --- diff --git a/tests/proton_tests/ssl.py b/tests/proton_tests/ssl.py index 8567b1b..237c3da 100644 --- a/tests/proton_tests/ssl.py +++ b/tests/proton_tests/ssl.py @@ -43,13 +43,32 @@ class SslTest(common.Test): self.t_client = None self.t_server = None -def _pump(self): +def _pump(self, buffer_size=1024): + +Make the transport send up to buffer_size bytes (this will be the AMQP +header and open frame) returning a buffer containing the bytes +sent. Transport is stateful so this will return 0 when it has +no more frames to send. +TODO this function is duplicated in sasl.py. Should be moved to a common place. + +out_client_leftover_by_server = +out_server_leftover_by_client = +i=0 while True: -out_client = self.t_client.output(1024) -out_server = self.t_server.output(1024) -if out_client: self.t_server.input(out_client) -if out_server: self.t_client.input(out_server) + +out_client = out_client_leftover_by_server + self.t_client.output(buffer_size) +out_server = out_server_leftover_by_client + self.t_server.output(buffer_size) + +if out_client: +number_server_consumed = self.t_server.input(out_client) +out_client_leftover_by_server = out_client[number_server_consumed:] # if it consumed everything then this is empty + +if out_server: +number_client_consumed = self.t_client.input(out_server) +out_server_leftover_by_client = out_server[number_client_consumed:] # if it consumed everything then this is empty + if not out_client and not out_server: break +i=i+1 def _testpath(self, file): Set the full path to the certificate,keyfile, etc. for the test. --- Several ssl tests now fail when run against proton-c, all with the same error. This surprised us because we hadn't started playing with the buffer size yet - we were still using the default of 1024. For example, test_server_authentication gives this output: proton_tests.ssl.SslTest.test_server_authentication .[0xa2ca208:0] ERROR[-2] SSL Failure: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac fail Error during test: Traceback (most recent call last): File ./tests/proton-test, line 331, in run phase() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 166, in test_server_authentication self._pump() File /home/phil/dev/proton/tests/proton_tests/ssl.py, line 63, in _pump number_server_consumed = self.t_server.input(out_client) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2141, in input return self._check(n) File /home/phil/dev/proton/proton-c/bindings/python/proton.py, line 2115, in _check raise
amqp redirect scenario details
Over the last few weeks we have created a number of JIRAs related to SSL resumption and redirects etc. All of these allude to some master redirect scenario but the scenario itself perhaps wasn't clear. Hopefully this note should give folks some more context as to the motivation and details for this scenario. We have a multi-tenant cloud messaging service that supports AMQP 1-0. One of our customers is building bandwidth constrained devices which require long lived connections to our service with the minimum amount of protocol chatter. There are potentially a large number of devices involved so byte overhead needs to be minimized, even an empty 8 byte keep-alive frame every 5 minutes, is quite prohibitive. We have recommended the customer use AMQP 1.0 with Proton-C in their Linux based devices. Now our service uses our standard cloud (Azure) infrastructure components and hence inherits some of the constraints of these components. Specifically the Azure load balancer, which this service sits behind, aggressively kills connections if there is no traffic for more than 5 minutes. The service however does have direct IP endpoints which are connectable but are dynamic. To satisfy the customer scenario and given our constraints, we need the client to connect to the well-known DNS name for the load balancer VIP and somehow redirect the client to that machine's direct IP address to work around the load balancer's idle connection limitation. AMQP redirection is a perfect fit for this. Given this background, here is how the complete redirect scenario works out: 1. Client establishes a TCP connection to the AMQP endpoint 2. Regular SSL/TLS session negotiation happens which involves a number of round trips between client/server 3. Client/Server do the SASL-PLAIN dance 4. Client sends AMQP open frame with open.hostname set to the AMQP endpoint address from (1) 5. Server sends back a close frame with an AMQP redirect error, this redirect error will contain the direct IP address of the same node 6. Client establishes a TCP connection to the direct IP 7. SSL resume is used to re-establish the TLS session 8. Client/Server do the SASL-PLAIN dance 9. Client sends AMQP open frame with open.hostname set to the AMQP endpoint address from (1) above 10.The server sends back a successful Open 11.At this point AMQP Connection establishment is complete. The client will periodically disconnect due to various reasons beyond our control. The key here is to let them reconnect with minimal byte overhead: 1. Client should reconnect to the direct IP using steps 6-11 above. 2. If the connection to the direct IP fails N times then client should fall back to the standard load balancer address. SSL session resume may be possible in some scenarios, but full SSL negotiation may be required. HTH! Thanks
[jira] [Resolved] (PROTON-65) Provide a AMQP 1.0 Message to JMS Message mapping logic/module
[ https://issues.apache.org/jira/browse/PROTON-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-65. Resolution: Fixed Fix Version/s: 0.3 Provide a AMQP 1.0 Message to JMS Message mapping logic/module -- Key: PROTON-65 URL: https://issues.apache.org/jira/browse/PROTON-65 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Assignee: Rob Godfrey Fix For: 0.3 Attachments: PROTON-65.patch Having a easy/consistent way to transform a JMS message to an AMQP message and back would be super handy. Having that logic live in proton would help make that mapping more standardized as different client and sever implementations can just re-use the logic. -- 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
[jira] [Resolved] (PROTON-22) Add optional module that provides HawtDispatch integration.
[ https://issues.apache.org/jira/browse/PROTON-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved PROTON-22. Resolution: Fixed Fix Version/s: 0.3 Add optional module that provides HawtDispatch integration. --- Key: PROTON-22 URL: https://issues.apache.org/jira/browse/PROTON-22 Project: Qpid Proton Issue Type: New Feature Components: proton-j Reporter: Hiram Chirino Fix For: 0.3 Attachments: PROTON-22-v5.patch HawtDispatch is a GCD style threading and IO handling framework. Would be nice if proton had nice integration /w it. -- 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
[jira] [Commented] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505958#comment-13505958 ] Andrew Stitcher commented on PROTON-168: I've made a couple of changes to the source tree which improve some of the issues noted here: (r1414960 r1414961) The code still won't compile on OS-X but it should now at least explain why it won't! Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
[jira] [Commented] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505960#comment-13505960 ] Andrew Stitcher commented on PROTON-168: Note that the patch attached here doesn't correctly fix the MSG_NOSIGPIPE issue as it just defines the macro to be SO_NOSIGPIPE which is not used in the same way: MSG_NOSIGPIPE is used as a flag value to send() SO_NOSIGPIPE is used to set a socket option with setsockopt() This patch will compile but it won't have the effect of avoiding SIGPIPE. Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
[jira] [Commented] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505963#comment-13505963 ] Hiram Chirino commented on PROTON-168: -- Running cmake on OS X now results in: - Looking for clock_gettime in rt -- Looking for clock_gettime in rt - not found -- Looking for clock_gettime -- Looking for clock_gettime - not found. CMake Error at CMakeLists.txt:116 (message): clock_gettime() not found Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
[jira] [Commented] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13505967#comment-13505967 ] Andrew Stitcher commented on PROTON-168: Cool - that's the effect I was expecting - it being slightly better to explain what is wrong than to error during the compilation! Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
[jira] [Updated] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-168: - Attachment: clock.patch Here's a patch that incorporates Mr Goldstein's OS X clock handling. Would that work? Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: clock.patch, proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
[jira] [Updated] (PROTON-168) Support for building on OS X
[ https://issues.apache.org/jira/browse/PROTON-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-168: - Attachment: nowerror.patch and here's a patch to disable -Werror on OSX Support for building on OS X Key: PROTON-168 URL: https://issues.apache.org/jira/browse/PROTON-168 Project: Qpid Proton Issue Type: New Feature Components: proton-c Environment: Mac OS X Lion Reporter: Andy Goldstein Priority: Minor Attachments: clock.patch, nowerror.patch, proton-168.patch, PROTON-168-v2.patch I did some quick hacky work to get proton-c to compile on my Mac running Lion. I also have homebrew installed and use that to supply any libraries that are necessary but not included by default on the Mac. I'm attaching my quick patch, and it would be great if someone could take it and update it so it's more robust and commit-quality :-) -- 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
PROTON - amqp 1.0 support
Hi, I'm trying to use the optional amqp 1.0 support for qpid within cmake, but I get the following message in debug mode: CMake Error at src/amqp.cmake:38 (message): Qpid proton not found, required for amqp 1.0 support. I have the environment system variables - PROTON_HOME and PROJECT_SOURCE_DIR set. Does anyone know what else I might need to set? I'm working in Windows and have a Windows version of proton working. I also had a qpid windows project setup, but I'm trying to setup the latest qpid code with amqp 1.0 support. Thanks, Mary
