[jira] [Created] (PROTON-931) proton-j: unable to determine if LINK_REMOTE_DETACH happened in response to a local detach
Dominic Evans created PROTON-931: Summary: proton-j: unable to determine if LINK_REMOTE_DETACH happened in response to a local detach Key: PROTON-931 URL: https://issues.apache.org/jira/browse/PROTON-931 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9.1 Reporter: Dominic Evans Fix For: 0.10 The Link `detached` state is required to assess when a LINK_REMOTE_DETACHED event is received as to whether or not it was as a result of a local detach or the remote end detaching the link for some other reason. Currently this is not exposed in the Link interface. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-844) proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024
[ https://issues.apache.org/jira/browse/PROTON-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-844. -- Resolution: Fixed proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024 - Key: PROTON-844 URL: https://issues.apache.org/jira/browse/PROTON-844 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Dominic Evans If a remote peer attempts to attach with a handle 1024, its advertised handle-max, a proton-j service will hit an ArrayIndexOutOfBoundsException in the call to getLinkFromRemoteHandle Similarly, if a proton-j client attempts to allocate a local handle when all 1024 are used up, it chooses UnsignedInteger.MAX_VALUE rather than throwing an Exception locally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-843) proton-j: Transport advertises idle timeout as-is whereas proton-c halves it before
Dominic Evans created PROTON-843: Summary: proton-j: Transport advertises idle timeout as-is whereas proton-c halves it before Key: PROTON-843 URL: https://issues.apache.org/jira/browse/PROTON-843 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Dominic Evans Assignee: Dominic Evans As discussed on the mailing list. Currently proton-j advertises its local idle timeout value as-is, whereas proton-c will halve it before sending it to the remote side. The should match in behaviour. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-844) proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024
Dominic Evans created PROTON-844: Summary: proton-j: ArrayIndexOutOfBounds exception if remote peer sends a handle 1024 Key: PROTON-844 URL: https://issues.apache.org/jira/browse/PROTON-844 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Dominic Evans If a remote peer attempts to attach with a handle 1024, its advertised handle-max, a proton-j service will hit an ArrayIndexOutOfBoundsException in the call to getLinkFromRemoteHandle Similarly, if a proton-j client attempts to allocate a local handle when all 1024 are used up, it chooses UnsignedInteger.MAX_VALUE rather than throwing an Exception locally. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reopened PROTON-834: -- Assignee: Dominic Evans proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates -- Key: PROTON-834 URL: https://issues.apache.org/jira/browse/PROTON-834 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Following on from the fixes made under PROTON-576, some UTF-8 characters were getting incorrectly reported as invalid surrogates, when they were valid 3-byte encodings. e.g., ！！！ (╯°□°)╯︵ ┻━┻ etc. This is an issue when streaming variable content such as Twitter messages which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-834: - Fix Version/s: (was: 0.9) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates -- Key: PROTON-834 URL: https://issues.apache.org/jira/browse/PROTON-834 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Following on from the fixes made under PROTON-576, some UTF-8 characters were getting incorrectly reported as invalid surrogates, when they were valid 3-byte encodings. e.g., ！！！ (╯°□°)╯︵ ┻━┻ etc. This is an issue when streaming variable content such as Twitter messages which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
Dominic Evans created PROTON-834: Summary: proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates Key: PROTON-834 URL: https://issues.apache.org/jira/browse/PROTON-834 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans Fix For: 0.9 Following on from the fixes made under PROTON-576, some UTF-8 characters were getting incorrectly reported as invalid surrogates, when they were valid 3-byte encodings. e.g., ！！！ (╯°□°)╯︵ ┻━┻ etc. This is an issue when streaming variable content such as Twitter messages which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-834) proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates
[ https://issues.apache.org/jira/browse/PROTON-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-834. -- Resolution: Fixed Pushed c65e897 proton-j: UTF-8 encoder reporting some three byte characters as invalid surrogates -- Key: PROTON-834 URL: https://issues.apache.org/jira/browse/PROTON-834 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans Fix For: 0.9 Following on from the fixes made under PROTON-576, some UTF-8 characters were getting incorrectly reported as invalid surrogates, when they were valid 3-byte encodings. e.g., ！！！ (╯°□°)╯︵ ┻━┻ etc. This is an issue when streaming variable content such as Twitter messages which can often contain such characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-832) messenger: next_drain is not reset for manual link credit mode in messenger
Dominic Evans created PROTON-832: Summary: messenger: next_drain is not reset for manual link credit mode in messenger Key: PROTON-832 URL: https://issues.apache.org/jira/browse/PROTON-832 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Fix For: 0.9 A messenger switched to using manual link credit mode (added under PROTON-679) should reset the next_drain value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-548. -- Resolution: Fixed Just noticed that the windows fix was comitted by [~chug] under commit b4fbb15, so marking this off as resolved commit b4fbb1504a005d449a7201eed8e5dd8ac6212ef5 Author: Chuck Rolke c...@redhat.com Date: Wed Dec 3 17:07:20 2014 -0500 QPID-548: IPv6 fix for Windows to create socket of correct address family. Patch from Dominic Evans. Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Assignee: Cliff Jansen Fix For: 0.9 Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-548. Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Assignee: Cliff Jansen Fix For: 0.9 Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-832) messenger: next_drain is not reset for manual link credit mode in messenger
[ https://issues.apache.org/jira/browse/PROTON-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reassigned PROTON-832: Assignee: Dominic Evans messenger: next_drain is not reset for manual link credit mode in messenger - Key: PROTON-832 URL: https://issues.apache.org/jira/browse/PROTON-832 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 A messenger switched to using manual link credit mode (added under PROTON-679) should reset the next_drain value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-832) messenger: next_drain is not reset for manual link credit mode in messenger
[ https://issues.apache.org/jira/browse/PROTON-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-832. -- Resolution: Fixed messenger: next_drain is not reset for manual link credit mode in messenger - Key: PROTON-832 URL: https://issues.apache.org/jira/browse/PROTON-832 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 A messenger switched to using manual link credit mode (added under PROTON-679) should reset the next_drain value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-154) proton-j: 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
]
Dominic Evans resolved PROTON-154.
--
Resolution: Fixed
Fix Version/s: 0.9
proton-j: 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
Assignee: Dominic Evans
Fix For: 0.9
Attachments: PROTON-154-test.patch, PROTON-154.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}, 2target=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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-154) proton-j: 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
]
Dominic Evans updated PROTON-154:
-
Summary: proton-j: link attach, detach, attach sequence on single session
does not result in a new link for the 2nd attach (was: link attach, detach,
attach sequence on single session does not result in a new link for the 2nd
attach)
proton-j: 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
Assignee: Dominic Evans
Attachments: PROTON-154-test.patch, PROTON-154.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}, 2target=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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (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
]
Dominic Evans reassigned PROTON-154:
Assignee: Dominic Evans
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
Assignee: Dominic Evans
Attachments: PROTON-154-test.patch, PROTON-154.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}, 2target=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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-154) proton-j: 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=14314293#comment-14314293
]
Dominic Evans commented on PROTON-154:
--
hit this issue on proton-j in HEAD, no longer appears to be an issue on
proton-c or any of the bindings thereof
proton-j: 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
Assignee: Dominic Evans
Attachments: PROTON-154-test.patch, PROTON-154.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}, 2target=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 was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-775) ruby: message annotations send from a ruby client are invalid
[ https://issues.apache.org/jira/browse/PROTON-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14309067#comment-14309067 ] Dominic Evans commented on PROTON-775: -- [~mcpierce] do you have any thoughts of how we might be able to fix this? ruby: message annotations send from a ruby client are invalid - Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-737) [PATCH] ruby: StateError not included in exceptions
[ https://issues.apache.org/jira/browse/PROTON-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reassigned PROTON-737: Assignee: Dominic Evans (was: Darryl L. Pierce) [PATCH] ruby: StateError not included in exceptions --- Key: PROTON-737 URL: https://issues.apache.org/jira/browse/PROTON-737 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Attachments: 42_add_missing_exception_to_ruby_bindings.patch Patch attached. I'm guessing this is just out of sync with proton-c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-737) [PATCH] ruby: StateError not included in exceptions
[ https://issues.apache.org/jira/browse/PROTON-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-737. [PATCH] ruby: StateError not included in exceptions --- Key: PROTON-737 URL: https://issues.apache.org/jira/browse/PROTON-737 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 42_add_missing_exception_to_ruby_bindings.patch Patch attached. I'm guessing this is just out of sync with proton-c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-814) proton-c: pn_selector_select caches its return code from a previous error
[ https://issues.apache.org/jira/browse/PROTON-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-814. -- Resolution: Fixed Fix Version/s: 0.9 proton-c: pn_selector_select caches its return code from a previous error - Key: PROTON-814 URL: https://issues.apache.org/jira/browse/PROTON-814 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 In posix pn_selector_select, if a poll() call returns result == -1 and sets selector-error from the errno, any subsequent pn_selector_select calls on the same selector will return have a return code of the previously cached errno even if they succeed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-814) proton-c: pn_selector_select caches its return code from a previous error
[ https://issues.apache.org/jira/browse/PROTON-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-814. proton-c: pn_selector_select caches its return code from a previous error - Key: PROTON-814 URL: https://issues.apache.org/jira/browse/PROTON-814 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 In posix pn_selector_select, if a poll() call returns result == -1 and sets selector-error from the errno, any subsequent pn_selector_select calls on the same selector will return have a return code of the previously cached errno even if they succeed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-483) detach with closed=false (or unspecified) not handled
[
https://issues.apache.org/jira/browse/PROTON-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans resolved PROTON-483.
--
Resolution: Fixed
I believe this is fixed by PROTON-677
detach with closed=false (or unspecified) not handled
-
Key: PROTON-483
URL: https://issues.apache.org/jira/browse/PROTON-483
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Reporter: Gordon Sim
Assignee: Dominic Evans
If an application using proton-c receives a detach frame where the closed
field is not set to true, then the state of the link doesn't change and the
application is essentially unaware that anything has been received (and
consequently can't respond).
From transport.c (line 882):
{noformat}
if (closed)
{
PN_SET_REMOTE(link-endpoint.state, PN_REMOTE_CLOSED);
} else {
// TODO: implement
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-483) detach with closed=false (or unspecified) not handled
[
https://issues.apache.org/jira/browse/PROTON-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans reassigned PROTON-483:
Assignee: Dominic Evans
detach with closed=false (or unspecified) not handled
-
Key: PROTON-483
URL: https://issues.apache.org/jira/browse/PROTON-483
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6
Reporter: Gordon Sim
Assignee: Dominic Evans
If an application using proton-c receives a detach frame where the closed
field is not set to true, then the state of the link doesn't change and the
application is essentially unaware that anything has been received (and
consequently can't respond).
From transport.c (line 882):
{noformat}
if (closed)
{
PN_SET_REMOTE(link-endpoint.state, PN_REMOTE_CLOSED);
} else {
// TODO: implement
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-814) proton-c: pn_selector_select caches its return code from a previous error
Dominic Evans created PROTON-814: Summary: proton-c: pn_selector_select caches its return code from a previous error Key: PROTON-814 URL: https://issues.apache.org/jira/browse/PROTON-814 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans In posix pn_selector_select, if a poll() call returns result == -1 and sets selector-error from the errno, any subsequent pn_selector_select calls on the same selector will return have a return code of the previously cached errno even if they succeed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-757) [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards
[ https://issues.apache.org/jira/browse/PROTON-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reassigned PROTON-757: Assignee: Dominic Evans [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards -- Key: PROTON-757 URL: https://issues.apache.org/jira/browse/PROTON-757 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Attachments: 0001-Don-t-trace-transport-errors-unless-PN_TRACE-set.patch This looks to be since e5696c19. pn_do_error already sets the transport-condition fields which are accessible as a pn_error from pn_transport_error, so we shouldn't really output them to stderr unless tracing is enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-757) [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards
[ https://issues.apache.org/jira/browse/PROTON-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-757. [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards -- Key: PROTON-757 URL: https://issues.apache.org/jira/browse/PROTON-757 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 0001-Don-t-trace-transport-errors-unless-PN_TRACE-set.patch This looks to be since e5696c19. pn_do_error already sets the transport-condition fields which are accessible as a pn_error from pn_transport_error, so we shouldn't really output them to stderr unless tracing is enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-751) [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error
[ https://issues.apache.org/jira/browse/PROTON-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-751. [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error - Key: PROTON-751 URL: https://issues.apache.org/jira/browse/PROTON-751 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 0001-If-pn_connect-fails-copy-io-error-to-messenger.patch If I attempt to put and send a message using messenger to a unresolvable DNS name, messenger just blocks indefinitely (or until timeout if one is set) and the getaddrinfo failure is never exposed to the user via messenger-error ``` e.g., $ bundle exec ruby send.rb -a madeup.example.com ``` The fix is to update pn_messenger_resolve to copy the error set on messenger-io to messenger-error in the event that PN_INVALID_SOCKET is returned by the pn_connect call (in the same way as we already do for pn_listener_ctx) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-757) [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards
[ https://issues.apache.org/jira/browse/PROTON-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-757. -- Resolution: Fixed Fix Version/s: 0.9 Pushed under 78e54ee [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards -- Key: PROTON-757 URL: https://issues.apache.org/jira/browse/PROTON-757 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 0001-Don-t-trace-transport-errors-unless-PN_TRACE-set.patch This looks to be since e5696c19. pn_do_error already sets the transport-condition fields which are accessible as a pn_error from pn_transport_error, so we shouldn't really output them to stderr unless tracing is enabled. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-751) [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error
[ https://issues.apache.org/jira/browse/PROTON-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reassigned PROTON-751: Assignee: Dominic Evans [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error - Key: PROTON-751 URL: https://issues.apache.org/jira/browse/PROTON-751 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 0001-If-pn_connect-fails-copy-io-error-to-messenger.patch If I attempt to put and send a message using messenger to a unresolvable DNS name, messenger just blocks indefinitely (or until timeout if one is set) and the getaddrinfo failure is never exposed to the user via messenger-error ``` e.g., $ bundle exec ruby send.rb -a madeup.example.com ``` The fix is to update pn_messenger_resolve to copy the error set on messenger-io to messenger-error in the event that PN_INVALID_SOCKET is returned by the pn_connect call (in the same way as we already do for pn_listener_ctx) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-751) [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error
[ https://issues.apache.org/jira/browse/PROTON-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-751. -- Resolution: Fixed Fix Version/s: 0.9 fixed in b9423d4 [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error - Key: PROTON-751 URL: https://issues.apache.org/jira/browse/PROTON-751 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Dominic Evans Fix For: 0.9 Attachments: 0001-If-pn_connect-fails-copy-io-error-to-messenger.patch If I attempt to put and send a message using messenger to a unresolvable DNS name, messenger just blocks indefinitely (or until timeout if one is set) and the getaddrinfo failure is never exposed to the user via messenger-error ``` e.g., $ bundle exec ruby send.rb -a madeup.example.com ``` The fix is to update pn_messenger_resolve to copy the error set on messenger-io to messenger-error in the event that PN_INVALID_SOCKET is returned by the pn_connect call (in the same way as we already do for pn_listener_ctx) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-775) ruby: message annotations send from a ruby client are invalid
Dominic Evans created PROTON-775: Summary: ruby: message annotations send from a ruby client are invalid Key: PROTON-775 URL: https://issues.apache.org/jira/browse/PROTON-775 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Since PROTON-616, proton-j has attempted to enforce the fact that the key's of a message annotations map *must* be of the Symbol type (or actually ulong, but those are reserved so we don't need to worry about that) [1] Unfortunately, from the Ruby client, the mapping of a native map into proton data always sets the key's as strings rather than symbols. In proton-j, you'll currently hit a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` if you try to look at keys of the MessageAnnotations object of a message sent from the ruby send.rb example (which sets message annotations for the keys 'version' and 'pill'). -- [1] http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-annotations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-776) proton-j: Message.decode doesn't validate all data types?
Dominic Evans created PROTON-776: Summary: proton-j: Message.decode doesn't validate all data types? Key: PROTON-776 URL: https://issues.apache.org/jira/browse/PROTON-776 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.8 Reporter: Dominic Evans PROTON-616 attempted to enfore that message annotation keys were of the Symbol type. However, it seems to be possible to send a map with strings keys for the message annotations section (e.g., via the ruby client) and message.decode will accept this. It is only when you try to use the MessageAnnotations map that you get a `java.lang.ClassCastException: java.lang.String incompatible with org.apache.qpid.proton.amqp.Symbol` exception because the underlying map isn't compatible with what the generics suggest. Isn't this something that we should catch at decode time? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: 08_fix_ipv6_windows.patch patch rebased against 0.8 Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Assignee: Cliff Jansen Fix For: 0.9 Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: (was: 08_fix_ipv6_windows.patch) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Assignee: Cliff Jansen Fix For: 0.9 Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-763) proton-c: pn_messenger_stop closes all links (detach w/ close=true) regardless of TTL / expiry
[ https://issues.apache.org/jira/browse/PROTON-763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-763: - Description: As discussed on IRC. https://issues.apache.org/jira/browse/PROTON-677 (git commit 111568af for reference) reworked the fix to add an explicit pn_link_detach. However, pn_messenger_stop will call pn_link_close for all links regardless of expiry/ttl. Ideally it should pn_link_detach for receiver links with expiry_policy PN_EXPIRE_NEVER or timeout0 Patch available at: https://gist.github.com/dnwe/844d0b21ef9e757f584b was: As discussed on IRC. https://issues.apache.org/jira/browse/PROTON-677 (git commit 111568af for reference) reworked the fix to add an explicit pn_link_detach. However, pn_messenger_stop will call pn_link_close for all links regardless of expiry/ttl. Ideally it should pn_link_detach for receiver links with expiry_policy PN_EXPIRE_NEVER or timeout0 Patch available at: https://gist.github.com/dnwe/844d0b21ef9e757f584 proton-c: pn_messenger_stop closes all links (detach w/ close=true) regardless of TTL / expiry -- Key: PROTON-763 URL: https://issues.apache.org/jira/browse/PROTON-763 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans As discussed on IRC. https://issues.apache.org/jira/browse/PROTON-677 (git commit 111568af for reference) reworked the fix to add an explicit pn_link_detach. However, pn_messenger_stop will call pn_link_close for all links regardless of expiry/ttl. Ideally it should pn_link_detach for receiver links with expiry_policy PN_EXPIRE_NEVER or timeout0 Patch available at: https://gist.github.com/dnwe/844d0b21ef9e757f584b -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-758) proton-c: assertion failure when SASL fails (PN_SASL_FAIL)
[ https://issues.apache.org/jira/browse/PROTON-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-758: - Description: As discussed on IRC When SASL negotiation fails (e.g., wrong type, bad user+pass etc.) and you're running on a debug build (no-optimization) you hit an assertion failure in 0.8 that didn't previously occur in 0.7 qpid-proton-0.8/proton-c/src/transport/transport.c:1073: transport_consume Assertion `n == (-1)' failed. It looks like this is because pn_sasl_input is returning PN_ERR when PN_SASL_FAIL has occurred. was: As discussed on IRC When SASL negotation fails (e.g., wrong type, bad user+pass etc.) and you're running on a debug build (no-optimization) you hit an assertion failure in 0.8 that didn't previously occur in 0.7 qpid-proton-0.8/proton-c/src/transport/transport.c:1073: transport_consume Assertion `n == (-1)' failed. It looks like this is because pn_sasl_input is returning PN_ERR when PN_SASL_FAIL has occurred. proton-c: assertion failure when SASL fails (PN_SASL_FAIL) -- Key: PROTON-758 URL: https://issues.apache.org/jira/browse/PROTON-758 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans As discussed on IRC When SASL negotiation fails (e.g., wrong type, bad user+pass etc.) and you're running on a debug build (no-optimization) you hit an assertion failure in 0.8 that didn't previously occur in 0.7 qpid-proton-0.8/proton-c/src/transport/transport.c:1073: transport_consume Assertion `n == (-1)' failed. It looks like this is because pn_sasl_input is returning PN_ERR when PN_SASL_FAIL has occurred. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-752) Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations
[ https://issues.apache.org/jira/browse/PROTON-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14223514#comment-14223514 ] Dominic Evans commented on PROTON-752: -- [~mcpierce] so I had a look at the patch, but I'm not sure adding new methods is necessarily the right answer here. In any case, I'm not suggesting that the calls should be non-blocking or run in a different Thread to the one that called them. The messenger calls should still be blocking (when messenger.blocking == true) on the Thread they were called, but they should unlock the Ruby GIL so that any other Ruby threads (which could be doing completely unrelated work) can make progress on that work in the interim. Once the messenger C code has run, the GIL lock will be acquired again when next eligible and the Thread will progress. The exact same issue can effects any of the messenger calls, not just receive. If I messenger.put a number of large messages and call messenger.send it will keep the GIL locked unnecessarily and prevent anything else in my Ruby app from making progress until that I/O has completed. RE: 1.8, I don't think you need to worry about this in the Ruby 1.8 case, as everything there is mapped onto a single operating-system thread so unlocking the GIL wouldn't reap any benefits (and hence why the method calls to unlock it weren't available). Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations --- Key: PROTON-752 URL: https://issues.apache.org/jira/browse/PROTON-752 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Assignee: Darryl L. Pierce Priority: Minor Attachments: 0001-PROTON-752-Provide-a-non-blocking-means-to-receive-m.patch Currently the I/O-style calls to the Cproton methods don't unlock the Ruby GIL, impacting performance as other Threads could be given time on the interpreter whilst the extension code is running. Depending on Ruby version this is simply a matter of wrapping the calls in rb_thread_call_without_gvl (Ruby 2.x +) or rb_thread_blocking_region (Ruby 1.9.x). On Ruby 1.8 I'm not sure if you can enable this, but its my understanding that RHEL requires continued support for 1.8, so some #define work would be needed to perform a no-op on that version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-752) Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations
Dominic Evans created PROTON-752: Summary: Ruby: Cproton calls don't unlock the GIL for blocking / long-running operations Key: PROTON-752 URL: https://issues.apache.org/jira/browse/PROTON-752 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Priority: Minor Currently the I/O-style calls to the Cproton methods don't unlock the Ruby GIL, impacting performance as other Threads could be given time on the interpreter whilst the extension code is running. Depending on Ruby version this is simply a matter of wrapping the calls in rb_thread_call_without_gvl (Ruby 2.x +) or rb_thread_blocking_region (Ruby 1.9.x). On Ruby 1.8 I'm not sure if you can enable this, but its my understanding that RHEL requires continued support for 1.8, so some #define work would be needed to perform a no-op on that version. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-751) [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error
Dominic Evans created PROTON-751: Summary: [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error Key: PROTON-751 URL: https://issues.apache.org/jira/browse/PROTON-751 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans If I attempt to put and send a message using messenger to a unresolvable DNS name, messenger just blocks indefinitely (or until timeout if one is set) and the getaddrinfo failure is never exposed to the user via messenger-error ``` e.g., $ bundle exec ruby send.rb -a madeup.example.com ``` The fix is to update pn_messenger_resolve to copy the error set on messenger-io to messenger-error in the event that PN_INVALID_SOCKET is returned by the pn_connect call (in the same way as we already do for pn_listener_ctx) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-751) [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error
[ https://issues.apache.org/jira/browse/PROTON-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-751: - Attachment: 0001-If-pn_connect-fails-copy-io-error-to-messenger.patch patch attached [PATCH] proton-c: pn_connect failures aren't exposed via messenger-error - Key: PROTON-751 URL: https://issues.apache.org/jira/browse/PROTON-751 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Dominic Evans Attachments: 0001-If-pn_connect-fails-copy-io-error-to-messenger.patch If I attempt to put and send a message using messenger to a unresolvable DNS name, messenger just blocks indefinitely (or until timeout if one is set) and the getaddrinfo failure is never exposed to the user via messenger-error ``` e.g., $ bundle exec ruby send.rb -a madeup.example.com ``` The fix is to update pn_messenger_resolve to copy the error set on messenger-io to messenger-error in the event that PN_INVALID_SOCKET is returned by the pn_connect call (in the same way as we already do for pn_listener_ctx) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-748) [PATCH] ruby: user doesn't have access to set settlement modes or messenger flags
[ https://issues.apache.org/jira/browse/PROTON-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-748: - Attachment: 0001-Add-support-for-Messenger-snd-rcv-modes-and-flags.patch patch attached [PATCH] ruby: user doesn't have access to set settlement modes or messenger flags - Key: PROTON-748 URL: https://issues.apache.org/jira/browse/PROTON-748 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Priority: Minor Attachments: 0001-Add-support-for-Messenger-snd-rcv-modes-and-flags.patch Currently there's no way for a Ruby user to set the settlement modes or behaviour flags used by the Messenger. NB: the setting of outgoing_window / incoming_window in the patch are sort of workarounds until I can establish why there is a check that those have been initialized (from 0) at https://github.com/apache/qpid-proton/blob/master/proton-c/src/messenger/messenger.c#L1724 which means the settlement changes don't have any effect by default. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-743) [PATCH] ruby: user doesn't have access to clear messenger error object
[ https://issues.apache.org/jira/browse/PROTON-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-743: - Attachment: 0001-Wrapper-pn_error-so-user-has-more-control-over-it.patch patch attached. [PATCH] ruby: user doesn't have access to clear messenger error object -- Key: PROTON-743 URL: https://issues.apache.org/jira/browse/PROTON-743 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Priority: Minor Attachments: 0001-Wrapper-pn_error-so-user-has-more-control-over-it.patch Once messenger error has been set and it has been read from messenger.error and logged / acted upon, it would be useful for the user to be able to clear the error object so they can continue operating. Wrappering it up in an Error class makes this easier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-634) Packages are needed for Ubuntu Precise (12 LTS)
[ https://issues.apache.org/jira/browse/PROTON-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200916#comment-14200916 ] Dominic Evans commented on PROTON-634: -- [~kgiusti] it seems this has already been fixed, in that https://launchpad.net/~qpid/+archive/ubuntu/released contains .debs for both trusty and precise now /cc [~rhs] [~mcpierce] Although technically even Lucid (10.04) is still supported until April 2015 on the server kernel. I'll raise a separate JIRA to ask Darryl to push up a 0.8 deb Packages are needed for Ubuntu Precise (12 LTS) --- Key: PROTON-634 URL: https://issues.apache.org/jira/browse/PROTON-634 Project: Qpid Proton Issue Type: Task Components: proton-c Affects Versions: 0.7 Reporter: Ken Giusti Priority: Minor Fix For: 0.9 Our PPA (ppa:qpid/released) only has proton packages for Ubuntu Trusty (14 LTS). Ubuntu Precise (12 LTS) is still supported by upstream - we should have packages for that also. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-738) Debian + Ubuntu Packages need updating to 0.8
Dominic Evans created PROTON-738: Summary: Debian + Ubuntu Packages need updating to 0.8 Key: PROTON-738 URL: https://issues.apache.org/jira/browse/PROTON-738 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.8 Reporter: Dominic Evans Priority: Minor It would be great if we could get 0.8 packages pushed to the development releases for debian and ubuntu https://tracker.debian.org/pkg/qpid-proton https://launchpad.net/ubuntu/+source/qpid-proton And debs for the LTS releases pushed to the PPA https://launchpad.net/~qpid/+archive/ubuntu/released -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-736) ruby: unable to send binary data?
Dominic Evans created PROTON-736:
Summary: ruby: unable to send binary data?
Key: PROTON-736
URL: https://issues.apache.org/jira/browse/PROTON-736
Project: Qpid Proton
Issue Type: Bug
Components: ruby-binding
Affects Versions: 0.8
Reporter: Dominic Evans
As discussed on irc with [~mcpierce]
I've not been able to determine how I can correctly send binary data using the
ruby gem.
From proton-c I can do this by (e.g.,)
{{
char* msgdata = Buffer::Data(buffer);
size_t msglen = Buffer::Length(buffer);
pn_message_set_format(msg-message, PN_DATA);
pn_message_load_data(msg-message, msgdata, msglen);
}}
and I assumed I might be able to do similar from Ruby by (e.g.,)
{{
data = File.binread(filename)
msg.format = Qpid::Proton::MessageFormat::DATA
msg.content = data
}}
But Ruby is reading the data into a string and the SWIG binding is still
expecting a byte* array here.
After our discussions on IRC I also investigated doing:
{{
filedata = File.binread(filename)
data = Qpid::Proton::Data.new
data.binary = filedata
msg.body = data
}}
but didn't have any luck with this approach either.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-737) [PATCH] ruby: StateError not included in exceptions
Dominic Evans created PROTON-737: Summary: [PATCH] ruby: StateError not included in exceptions Key: PROTON-737 URL: https://issues.apache.org/jira/browse/PROTON-737 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Patch attached. I'm guessing this is just out of sync with proton-c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-737) [PATCH] ruby: StateError not included in exceptions
[ https://issues.apache.org/jira/browse/PROTON-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-737: - Attachment: 42_add_missing_exception_to_ruby_bindings.patch [PATCH] ruby: StateError not included in exceptions --- Key: PROTON-737 URL: https://issues.apache.org/jira/browse/PROTON-737 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans Attachments: 42_add_missing_exception_to_ruby_bindings.patch Patch attached. I'm guessing this is just out of sync with proton-c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-736) ruby: unable to send binary data?
[
https://issues.apache.org/jira/browse/PROTON-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14196358#comment-14196358
]
Dominic Evans commented on PROTON-736:
--
[~mcpierce] as discussed on IRC
The problem here is that ruby doesn't really differentiate between Binary data
and (utf-8) String data. The IO.binread [1] method just reads that data into a
string primitive and marks it as rb:ASCII-8BIT to prevent any encoding/decoding
or line-ending changes from taking place on it. This can be seen in the
mapping.rb code by the fact that the AMQP Binary type has klasses=nil for Ruby.
As such, if you use the message.body= setter and give it a String, you will
always end up with the message body being encoded as an AmqpValue containing a
String type. However, this is actually a spec-incompliant behaviour, because
the spec states that a String type will only contain UTF-8 encoded data. Hence,
if you try to receive that message using either a proton-j or python client the
String will fail to decode.
Its not obvious what the correct fix here would be, but I'd suggest something
along the lines of:
1) raise an exception in msg.body= if you pass a string primitive that doesn't
contain valid UTF-8
2) add the ability in message.rb to set your own arbitary Qpid::Proton::Data
object as the message body and map to and from that rather than ruby primitives
if it has been used
--
[1] http://ruby-doc.org/core-1.9.2/IO.html#method-c-binread
ruby: unable to send binary data?
-
Key: PROTON-736
URL: https://issues.apache.org/jira/browse/PROTON-736
Project: Qpid Proton
Issue Type: Bug
Components: ruby-binding
Affects Versions: 0.8
Reporter: Dominic Evans
Assignee: Darryl L. Pierce
Attachments:
0001-PROTON-736-Ruby-Message-does-not-return-all-content.patch
As discussed on irc with [~mcpierce]
I've not been able to determine how I can correctly send binary data using
the ruby gem.
From proton-c I can do this by (e.g.,)
{{
char* msgdata = Buffer::Data(buffer);
size_t msglen = Buffer::Length(buffer);
pn_message_set_format(msg-message, PN_DATA);
pn_message_load_data(msg-message, msgdata, msglen);
}}
and I assumed I might be able to do similar from Ruby by (e.g.,)
{{
data = File.binread(filename)
msg.format = Qpid::Proton::MessageFormat::DATA
msg.content = data
}}
But Ruby is reading the data into a string and the SWIG binding is still
expecting a byte* array here.
After our discussions on IRC I also investigated doing:
{{
filedata = File.binread(filename)
data = Qpid::Proton::Data.new
data.binary = filedata
msg.body = data
}}
but didn't have any luck with this approach either.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-725) pni_parse_url does not properly handle Base64 in URL
[
https://issues.apache.org/jira/browse/PROTON-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182596#comment-14182596
]
Dominic Evans commented on PROTON-725:
--
[~E528527] this is what URL encoding was designed for? :) You should replace
any reserved characters in the password before using it in the amqp:// URL
See http://en.wikipedia.org/wiki/Percent-encoding
%2F would replace the / in your password
pni_parse_url does not properly handle Base64 in URL
Key: PROTON-725
URL: https://issues.apache.org/jira/browse/PROTON-725
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd
Priority: Minor
Our provisioning system provides us with a password in Base64 format, which
can actually contain a slash character(s): '/'
This breaks the ability of {{pni_parse_url()}} to handle such URLs.
Example of URL string on which the parsing fails:
{{amqps://0ABCDEF1:/ExlxtfN+UxfExRxuwxIeFxeFzXLxxg+fxPx3x8xxU=@myself.servicebus.windows.net/out/t/Subscriptions/s}}
Instead of filling up the user and password variables, it puts the actual
contents to host and port.
With the actual code it is a correct behavior - and *it is* also mentioned in
the comment right in front of the pni_parse_url() function.
Yet I would need an update to the functionality, to handle the Base64 in
password properly (anyone on Azure platform might run to this issue, soon or
later).
Note. I'm running the SVN rev 1633464 (latest trunk of 10/23/2014) version of
ProtonC (C / Linux).
Thanks for looking at this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: 02_fix_stringtype_encode_decode.patch)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: 02_fix_stringtype_encode_decode.patch
Patch refreshed.
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
Attachments: 02_fix_stringtype_encode_decode.patch
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 03_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_transport.h.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_messenger.c.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-574) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure
[ https://issues.apache.org/jira/browse/PROTON-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-574: - Attachment: (was: 08_return_sasl_auth_errors_transport.c.patch) proton-c: Messenger doesn't indicate when connection is aborted for a SASL negotation failure - Key: PROTON-574 URL: https://issues.apache.org/jira/browse/PROTON-574 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Attachments: 05_return_sasl_auth_errors_messenger.c.patch, 05_return_sasl_auth_errors_transport.c.patch, 05_return_sasl_auth_errors_transport.h.patch Currently if a Messenger's connection is aborted at the remote end, there's no differentiation between the connection just being dropped and a failure to negotiate SASL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-669) proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc.
Dominic Evans created PROTON-669: Summary: proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc. Key: PROTON-669 URL: https://issues.apache.org/jira/browse/PROTON-669 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans As previously discussed on the mailing list under [Using the messenger API to connect to a server without sending or subscribing|http://qpid.2158936.n2.nabble.com/Using-the-messenger-API-to-connect-to-a-server-without-sending-or-subscribing-td7607184.html]; Messenger doesn't provide a way of requesting a connection. Messenger has been designed to abstract away the notion of establishing connections from the user, but we would like to fail fast in those situations and return authentication errors (e.g.,) to the user. Rafa suggested that we could add an option to messenger to enable the checking of routes at startup, which is what the attached patch intends to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: (was: 14_fix_ipv6_windows.patch) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-548) Proton-C driver and URL Parsers don't support AF_INET6 (IPv6)
[ https://issues.apache.org/jira/browse/PROTON-548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-548: - Attachment: 08_fix_ipv6_windows.patch Proton-C driver and URL Parsers don't support AF_INET6 (IPv6) - Key: PROTON-548 URL: https://issues.apache.org/jira/browse/PROTON-548 Project: Qpid Proton Issue Type: Bug Components: proton-c, proton-j Affects Versions: 0.6 Reporter: Ted Ross Attachments: 08_fix_ipv6_windows.patch The proton-c driver hard-codes its sockets to AF_INET, rather than using the address family associated with a particular address. On systems that enable IPv6, the address localhost cannot be used because it resolves to ::1 rather than 127.0.0.1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-669) proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc.
[ https://issues.apache.org/jira/browse/PROTON-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-669: - Attachment: 07_add_messenger_route_check_on_start_transform.h.patch 07_add_messenger_route_check_on_start_transform.c.patch proton-c: Messenger abstracts away connections, but it would be useful to fail fast for auth errors etc. Key: PROTON-669 URL: https://issues.apache.org/jira/browse/PROTON-669 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 07_add_messenger_route_check_on_start.patch, 07_add_messenger_route_check_on_start_header.patch, 07_add_messenger_route_check_on_start_transform.c.patch, 07_add_messenger_route_check_on_start_transform.h.patch As previously discussed on the mailing list under [Using the messenger API to connect to a server without sending or subscribing|http://qpid.2158936.n2.nabble.com/Using-the-messenger-API-to-connect-to-a-server-without-sending-or-subscribing-td7607184.html]; Messenger doesn't provide a way of requesting a connection. Messenger has been designed to abstract away the notion of establishing connections from the user, but we would like to fail fast in those situations and return authentication errors (e.g.,) to the user. Rafa suggested that we could add an option to messenger to enable the checking of routes at startup, which is what the attached patch intends to do. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-578) proton-c: windows/io.c prints Unknown error for all winsock errors
[ https://issues.apache.org/jira/browse/PROTON-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-578: - Attachment: 10_fix_winsock_error_code_printing.patch proton-c: windows/io.c prints Unknown error for all winsock errors Key: PROTON-578 URL: https://issues.apache.org/jira/browse/PROTON-578 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Cliff Jansen Attachments: 10_fix_winsock_error_code_printing.patch The code in windows/io.c is attempting to call strerror on Winsock WSA error codes returned by WSAGetLastError(). However, these codes don't map to Unix errno codes, so will always output an Unknown error msg. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-578) proton-c: windows/io.c prints Unknown error for all winsock errors
[ https://issues.apache.org/jira/browse/PROTON-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-578: - Attachment: (was: 17_fix_winsock_error_code_printing.patch) proton-c: windows/io.c prints Unknown error for all winsock errors Key: PROTON-578 URL: https://issues.apache.org/jira/browse/PROTON-578 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Cliff Jansen Attachments: 10_fix_winsock_error_code_printing.patch The code in windows/io.c is attempting to call strerror on Winsock WSA error codes returned by WSAGetLastError(). However, these codes don't map to Unix errno codes, so will always output an Unknown error msg. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 02_set_pn_error_when_printing_connection_errors.patch 02_replace_perror_printing_with_error_setting_posix_driver.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 02_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
Dominic Evans created PROTON-670: Summary: proton-c: Messenger doesn't provide accessors for the links it is using Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
[ https://issues.apache.org/jira/browse/PROTON-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-670: - Attachment: 12_get_link_from_tracker_messenger.h.patch 12_get_link_from_tracker_messenger.c.patch proton-c: Messenger doesn't provide accessors for the links it is using --- Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 12_get_link_from_tracker_messenger.c.patch, 12_get_link_from_tracker_messenger.h.patch Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-670) proton-c: Messenger doesn't provide accessors for the links it is using
[ https://issues.apache.org/jira/browse/PROTON-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129860#comment-14129860 ] Dominic Evans commented on PROTON-670: -- patches attached to allow user to determine the link associated with a particular message by tracker entry proton-c: Messenger doesn't provide accessors for the links it is using --- Key: PROTON-670 URL: https://issues.apache.org/jira/browse/PROTON-670 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 12_get_link_from_tracker_messenger.c.patch, 12_get_link_from_tracker_messenger.h.patch Messenger doesn't provide accessors for the links it uses. As a consuming application that is using the Messenger API, it would be helpful to have access to this information so that you can determine which subscription address a given message was received upon. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: (was: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch 13_add_pn_messenger_set_settle_mode_functions.patch proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: (was: 13_add_pn_messenger_set_settle_mode_functions.patch) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch, 13_add_pn_messenger_set_settle_mode_functions_to_header.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-671) proton-c: Messenger doesn't provide a way to set the link settlement modes it uses
[ https://issues.apache.org/jira/browse/PROTON-671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-671: - Attachment: 13_add_pn_messenger_set_settle_mode_functions_to_header.patch 13_add_pn_messenger_set_settle_mode_functions.patch proton-c: Messenger doesn't provide a way to set the link settlement modes it uses --- Key: PROTON-671 URL: https://issues.apache.org/jira/browse/PROTON-671 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 13_add_pn_messenger_set_settle_mode_functions.patch, 13_add_pn_messenger_set_settle_mode_functions_to_header.patch Messenger doesn't provide a way to set link settlement modes. Messenger defaults to PN_SND_SETTLED and PN_RCV_FIRST and doesn't provide a way to override that behaviour. Patches attached to allow these to be configured. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
Dominic Evans created PROTON-672: Summary: proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
[ https://issues.apache.org/jira/browse/PROTON-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-672: - Attachment: 14_add_tracer_to_messenger.h.patch 14_add_tracer_to_messenger.c.patch proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 14_add_tracer_to_messenger.c.patch, 14_add_tracer_to_messenger.h.patch Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-672) proton-c: Messenger doesn't support setting the transport tracer
[ https://issues.apache.org/jira/browse/PROTON-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-672: - Attachment: 15_get_connection_from_transport.h.patch 15_get_connection_from_transport.c.patch proton-c: Messenger doesn't support setting the transport tracer Key: PROTON-672 URL: https://issues.apache.org/jira/browse/PROTON-672 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 14_add_tracer_to_messenger.c.patch, 14_add_tracer_to_messenger.h.patch, 15_get_connection_from_transport.c.patch, 15_get_connection_from_transport.h.patch Messenger doesn't support setting the transport tracer. Messenger ought to provide a way to allow the transport tracer function to be overriden so that tracing can be captured by the consuming application. Patches attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-673) proton-c: Messenger doesn't provide a way to obtain the remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-673: - Attachment: 19_add_get_remote_idle_timeout_to_messenger.h.patch 19_add_get_remote_idle_timeout_to_messenger.c.patch proton-c: Messenger doesn't provide a way to obtain the remote idle timeout --- Key: PROTON-673 URL: https://issues.apache.org/jira/browse/PROTON-673 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 19_add_get_remote_idle_timeout_to_messenger.c.patch, 19_add_get_remote_idle_timeout_to_messenger.h.patch Messenger doesn't provide a way to obtain the remote idle timeout which is required to ensure the client application can maintain the keep alive heartbeat, i.e. by calling pn_messenger_work at a sufficiently regular rate. Patch attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-673) proton-c: Messenger doesn't provide a way to obtain the remote idle timeout
Dominic Evans created PROTON-673: Summary: proton-c: Messenger doesn't provide a way to obtain the remote idle timeout Key: PROTON-673 URL: https://issues.apache.org/jira/browse/PROTON-673 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 19_add_get_remote_idle_timeout_to_messenger.c.patch, 19_add_get_remote_idle_timeout_to_messenger.h.patch Messenger doesn't provide a way to obtain the remote idle timeout which is required to ensure the client application can maintain the keep alive heartbeat, i.e. by calling pn_messenger_work at a sufficiently regular rate. Patch attached to implement this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 21_improve_perror_printing_windows_io.c.patch 21_improve_perror_printing_posix_io.c.patch 21_improve_perror_printing_messenger.c.patch 21_improve_perror_printing_io.h.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129889#comment-14129889 ] Dominic Evans commented on PROTON-571: -- Additional patchset to fix Windows socket errors. proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-674) proton-c: Messenger doesn't provide a way of setting the TTL on a subscription
Dominic Evans created PROTON-674: Summary: proton-c: Messenger doesn't provide a way of setting the TTL on a subscription Key: PROTON-674 URL: https://issues.apache.org/jira/browse/PROTON-674 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide a way of setting ttl on a subscription. We want to be able to specify the timeout of a given subscription link when we open it. Patches attached to add pn_messenger_subscribe_ttl call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-674) proton-c: Messenger doesn't provide a way of setting the TTL on a subscription
[ https://issues.apache.org/jira/browse/PROTON-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-674: - Attachment: 22_add_messenger_subscribe_ttl_method_messenger.h.patch 22_add_messenger_subscribe_ttl_method_messenger.c.patch proton-c: Messenger doesn't provide a way of setting the TTL on a subscription -- Key: PROTON-674 URL: https://issues.apache.org/jira/browse/PROTON-674 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 22_add_messenger_subscribe_ttl_method_messenger.c.patch, 22_add_messenger_subscribe_ttl_method_messenger.h.patch Messenger doesn't provide a way of setting ttl on a subscription. We want to be able to specify the timeout of a given subscription link when we open it. Patches attached to add pn_messenger_subscribe_ttl call. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-675) proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode
Dominic Evans created PROTON-675: Summary: proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode Key: PROTON-675 URL: https://issues.apache.org/jira/browse/PROTON-675 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Messenger doesn't provide a way of setting the SSL peer authentication mode when a trust certificate is being used (it is hardcoded to: PN_SSL_VERIFY_PEER_NAME). We want the option to be able to optionally specify PN_SSL_VERIFY_PEER instead. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-675) proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode
[ https://issues.apache.org/jira/browse/PROTON-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-675: - Attachment: 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.h.patch 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.c.patch proton-c: Messenger doesn't provide a way of setting the SSL peer authentication mode - Key: PROTON-675 URL: https://issues.apache.org/jira/browse/PROTON-675 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.c.patch, 23_add_messenger_set_ssl_peer_authentication_mode_method_messenger.h.patch Messenger doesn't provide a way of setting the SSL peer authentication mode when a trust certificate is being used (it is hardcoded to: PN_SSL_VERIFY_PEER_NAME). We want the option to be able to optionally specify PN_SSL_VERIFY_PEER instead. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-676) proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable
Dominic Evans created PROTON-676: Summary: proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable Key: PROTON-676 URL: https://issues.apache.org/jira/browse/PROTON-676 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 24_ssl_transport_failure_fix_messenger.c.patch When an ssl failure occurs during connection at the transport layer the error is not propagated back to messenger (it is ignored). Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-660) Fix openssl.c build on windows
[ https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-660: - Attachment: 25_openssl_fix_for_windows_platform.h.patch 25_openssl_fix_for_windows_data.h.patch 25_openssl_fix_for_windows_CMakeLists.patch We happend to have similarly hit this issue, but fixed it in a slightly different way, so I'm attaching our patches for reference as well. These include a patch to CMakeLists.txt to allow a OPENSSL_INCLUDE_DIR param to be supplied at build time. Fix openssl.c build on windows -- Key: PROTON-660 URL: https://issues.apache.org/jira/browse/PROTON-660 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Environment: Windows 7, VS2013 Reporter: Bozo Dragojevic Attachments: 0001-PROTON-660-Fix-openssl.c-build-on-windows.patch, 25_openssl_fix_for_windows_CMakeLists.patch, 25_openssl_fix_for_windows_data.h.patch, 25_openssl_fix_for_windows_platform.h.patch Compiled openssl-1.0.1i from source Proton finds it, but openssl.c does not compile without small adjustments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-677) proton-c: transport incorrectly detaches all links with closed=true by default
[ https://issues.apache.org/jira/browse/PROTON-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-677: - Attachment: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch proton-c: transport incorrectly detaches all links with closed=true by default -- Key: PROTON-677 URL: https://issues.apache.org/jira/browse/PROTON-677 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 26_stop_link_detach_closed_if_sub_ttl_transport.c.patch qpid-proton detaches all links with closed=true by default. If a subscription has a time-to-live and is not expected to be destroyed on detach then we shouldn't be setting closed=true on the detach call. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
Dominic Evans created PROTON-678: Summary: proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-678) proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used
[ https://issues.apache.org/jira/browse/PROTON-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-678: - Attachment: 27_32bit_windows_fix_transport.c.patch proton-c: (Win 32-bit) pn_post_frame misinterprets variable argument data when ERROR is used Key: PROTON-678 URL: https://issues.apache.org/jira/browse/PROTON-678 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Environment: Windows x86-32 Reporter: Dominic Evans Attachments: 27_32bit_windows_fix_transport.c.patch For Windows 32bit ERROR is not a uint64_t type, which causes pn_post_frame to misinterpret the passed variable argument data when ERROR is used patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-680) proton-c: Messenger doesn't provide a way of obtaining link or delivery information
[ https://issues.apache.org/jira/browse/PROTON-680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-680: - Attachment: 31_access_messenger_deliveries_messenger.h.patch 30_access_messenger_deliveries_messenger.c.patch 29_access_messenger_links_messenger.h.patch 29_access_messenger_links_messenger.c.patch proton-c: Messenger doesn't provide a way of obtaining link or delivery information --- Key: PROTON-680 URL: https://issues.apache.org/jira/browse/PROTON-680 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 29_access_messenger_links_messenger.c.patch, 29_access_messenger_links_messenger.h.patch, 30_access_messenger_deliveries_messenger.c.patch, 31_access_messenger_deliveries_messenger.h.patch This would be useful for determining why a delivery was rejected by the server (for example). Patches attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: 02_set_pn_error_when_printing_connection_errors.patch proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-571) proton-c: Messenger outputs errors to stderr rather than setting messenger-error
[ https://issues.apache.org/jira/browse/PROTON-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-571: - Attachment: (was: 02_set_pn_error_when_printing_connection_errors.patch) proton-c: Messenger outputs errors to stderr rather than setting messenger-error - Key: PROTON-571 URL: https://issues.apache.org/jira/browse/PROTON-571 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 02_replace_perror_printing_with_error_setting_posix_driver.patch, 02_set_pn_error_when_printing_connection_errors.patch, 21_improve_perror_printing_io.h.patch, 21_improve_perror_printing_messenger.c.patch, 21_improve_perror_printing_posix_io.c.patch, 21_improve_perror_printing_windows_io.c.patch For various errors, such as aborted connections, messenger simply outputs them to stderr rather then setting messenger-error. This makes it harder to drive from wrappering applications. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-681) proton-c: pni_map_ensure infinite loop if `load = map-load_factor`
[ https://issues.apache.org/jira/browse/PROTON-681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129960#comment-14129960 ] Dominic Evans commented on PROTON-681: -- [~gemmellr] yep you're correct, looks like this is a dupe. I didn't spot that when I searched to see if the issue was already reported. Will close this one off as fixed. proton-c: pni_map_ensure infinite loop if `load = map-load_factor` --- Key: PROTON-681 URL: https://issues.apache.org/jira/browse/PROTON-681 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 33_pni_map_ensure_bug_fix_object.c.patch Fix to a bug in pni_map_ensure, where it does not account for the case were load = map-load_factor, results in an infinite loop. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-681) proton-c: pni_map_ensure infinite loop if `load = map-load_factor`
[ https://issues.apache.org/jira/browse/PROTON-681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans resolved PROTON-681. -- Resolution: Duplicate Closing as dupe. proton-c: pni_map_ensure infinite loop if `load = map-load_factor` --- Key: PROTON-681 URL: https://issues.apache.org/jira/browse/PROTON-681 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 33_pni_map_ensure_bug_fix_object.c.patch Fix to a bug in pni_map_ensure, where it does not account for the case were load = map-load_factor, results in an infinite loop. Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-611) [proton-c] transport buffer increased to peer's max frame size if initial output_size is not enough
[ https://issues.apache.org/jira/browse/PROTON-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-611. [proton-c] transport buffer increased to peer's max frame size if initial output_size is not enough --- Key: PROTON-611 URL: https://issues.apache.org/jira/browse/PROTON-611 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Andrew Stitcher Fix For: 0.8 Attachments: 20_fix_bad_malloc_in_transport_produce.patch transport_produce attempts to allocate a negatively sized buffer As soon as remote_max_frame is set, the code in transport_produce attempts to increase its buffer immediately up to that size when its initial size isn't enough. This causes a huge malloc to occur if the remote max frame size is large and also potentially overflows MAX_INT -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (PROTON-573) proton-c: Messenger appears to have hard-coded address limits of 1024
[ https://issues.apache.org/jira/browse/PROTON-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-573. proton-c: Messenger appears to have hard-coded address limits of 1024 - Key: PROTON-573 URL: https://issues.apache.org/jira/browse/PROTON-573 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Assignee: Rafael H. Schloming Attachments: 06_arbitrary_length_addresses_in_store.patch, 07_arbitrary_length_addresses_in_messenger.patch The AMQP 1.0 spec permits pretty much arbitrary length link names, but Messenger hard-codes some 1K limits in various places. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-682) proton-c: a call to pn_messenger_stop can get into an infinite loop if the remote connection is severed
Dominic Evans created PROTON-682: Summary: proton-c: a call to pn_messenger_stop can get into an infinite loop if the remote connection is severed Key: PROTON-682 URL: https://issues.apache.org/jira/browse/PROTON-682 Project: Qpid Proton Issue Type: Bug Reporter: Dominic Evans The problem is that the transport layer is not being closed down properly if output is pending when the connection is severed and a messenger stop is requested. pn_messenger_stop needs to send out an AMQP close message any will only do this when there is an event to say that it can write (i.e pn_messenger_process gets a PN_WRITABLE event from pn_selector_next, which examines the pollfd and sets PN_WRITABLE event if POLLOUT is set in revents). Because this event is never generated it seems to loop forever. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-610) proton-c: messenger doesn't honour an advertised remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-610: - Attachment: 0001-ensure-messenger-honours-remote-idle-timeout.patch Updated patch, with accompanying messenger unittest proton-c: messenger doesn't honour an advertised remote idle timeout Key: PROTON-610 URL: https://issues.apache.org/jira/browse/PROTON-610 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 0001-ensure-messenger-honours-remote-idle-timeout.patch The changes under PROTON-111 added support to the underlying proton engine for honouring a remote idle timeout (as per the AMQP 1.0 spec) and sending empty null frames on a heartbeat interval to prevent the idle timeout expiring (and hence causing the client to be disconnect), However, the Messenger API doesn't currently drive the same behaviour and so will be disconnected from any broker that has implemented such a timeout. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-610) proton-c: messenger doesn't honour an advertised remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14101161#comment-14101161 ] Dominic Evans commented on PROTON-610: -- [~astitcher] updated patch attached with a simple test added to `tests/python/proton_tests/messenger.py` to confirm that messenger honours a remote idle timeout and sends heartbeat frames to keep the connector alive. Test fails on vanilla trunk, passes once the change to messenger.c has been applied. proton-c: messenger doesn't honour an advertised remote idle timeout Key: PROTON-610 URL: https://issues.apache.org/jira/browse/PROTON-610 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 0001-ensure-messenger-honours-remote-idle-timeout.patch The changes under PROTON-111 added support to the underlying proton engine for honouring a remote idle timeout (as per the AMQP 1.0 spec) and sending empty null frames on a heartbeat interval to prevent the idle timeout expiring (and hence causing the client to be disconnect), However, the Messenger API doesn't currently drive the same behaviour and so will be disconnected from any broker that has implemented such a timeout. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-610) proton-c: messenger doesn't honour an advertised remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-610: - Attachment: (was: 0001-ensure-messenger-honours-remote-idle-timeout.patch) proton-c: messenger doesn't honour an advertised remote idle timeout Key: PROTON-610 URL: https://issues.apache.org/jira/browse/PROTON-610 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 0001-ensure-messenger-honours-remote-idle-timeout.patch The changes under PROTON-111 added support to the underlying proton engine for honouring a remote idle timeout (as per the AMQP 1.0 spec) and sending empty null frames on a heartbeat interval to prevent the idle timeout expiring (and hence causing the client to be disconnect), However, the Messenger API doesn't currently drive the same behaviour and so will be disconnected from any broker that has implemented such a timeout. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-610) proton-c: messenger doesn't honour an advertised remote idle timeout
[ https://issues.apache.org/jira/browse/PROTON-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14097597#comment-14097597 ] Dominic Evans commented on PROTON-610: -- [~astitcher] thanks for looking at this issue. Sure, I can take a look at knocking up a unit test for this. proton-c: messenger doesn't honour an advertised remote idle timeout Key: PROTON-610 URL: https://issues.apache.org/jira/browse/PROTON-610 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Attachments: 0001-ensure-messenger-honours-remote-idle-timeout.patch The changes under PROTON-111 added support to the underlying proton engine for honouring a remote idle timeout (as per the AMQP 1.0 spec) and sending empty null frames on a heartbeat interval to prevent the idle timeout expiring (and hence causing the client to be disconnect), However, the Messenger API doesn't currently drive the same behaviour and so will be disconnected from any broker that has implemented such a timeout. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-576) proton-j: codec support for UTF-8 encoding and decoding appears broken?
[
https://issues.apache.org/jira/browse/PROTON-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominic Evans updated PROTON-576:
-
Attachment: (was: benchmark-src.zip)
proton-j: codec support for UTF-8 encoding and decoding appears broken?
---
Key: PROTON-576
URL: https://issues.apache.org/jira/browse/PROTON-576
Project: Qpid Proton
Issue Type: Bug
Components: proton-j
Affects Versions: 0.7
Reporter: Dominic Evans
It seems like Proton-J has its own custom UTF-8 encoder, but relies on Java
String's built-in UTF-8 decoder. However, the code doesn't seem quite right
and complex double byte UTF-8 like emoji ('') can quite easily fail to
parse:
| | Cause:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | Message:1 :- Cannot parse String
| | StackTrace:1 :- java.lang.IllegalArgumentException: Cannot parse
String
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:48)
| | at
org.apache.qpid.proton.codec.StringType$1.decode(StringType.java:36)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readRaw(DecoderImpl.java:945)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:172)
| | at
org.apache.qpid.proton.codec.StringType$AllStringEncoding.readValue(StringType.java:124)
| | at
org.apache.qpid.proton.codec.DynamicTypeConstructor.readValue(DynamicTypeConstructor.java:39)
| | at
org.apache.qpid.proton.codec.DecoderImpl.readObject(DecoderImpl.java:885)
| | at
org.apache.qpid.proton.message.impl.MessageImpl.decode(MessageImpl.java:629)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
