[jira] [Commented] (PROTON-969) Cyrus SASL module calls sasl_server_init once for every incoming connection
[ https://issues.apache.org/jira/browse/PROTON-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649213#comment-14649213 ] Dominic Evans commented on PROTON-969: -- It seems like these calls would increment a refcount and hence you would need to call sasl_server_done() and sasl_client_done() the same number of times before the cleanup mechanisms would actually kick-in and free up the memory > Cyrus SASL module calls sasl_server_init once for every incoming connection > --- > > Key: PROTON-969 > URL: https://issues.apache.org/jira/browse/PROTON-969 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Ted Ross >Assignee: Andrew Stitcher > Fix For: 0.10 > > > The Cyrus SASL module invokes sasl_server_init once for every incoming > connection on a listener. The Manpage for sasl_server_init states that it > should be called only once per process. > Is this a blocker for 0.10? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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] [Commented] (PROTON-885) Allow setup.py to bundle qpid-proton
[ https://issues.apache.org/jira/browse/PROTON-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14542731#comment-14542731 ] Dominic Evans commented on PROTON-885: -- Whilst I really like the idea of being able to pip install the proton client with no other dependencies installed on the machine – I think we'd need to be careful about the provenance of the changes in this patch... Whilst it does mention the source in the header "...libraries like PyZMQ (from which this work took lots of inspiration)..." and in some of the comments in the files. The added files are actually pretty much identical to those found in pyzmq's tree: https://github.com/zeromq/pyzmq/tree/master/buildutils/bundle.py https://github.com/zeromq/pyzmq/tree/master/buildutils/msg.py (log.py) https://github.com/zeromq/pyzmq/tree/master/buildutils/misc.py As such, the patch probably needs to be a bit more explicit about where they came from, and if they were merged in then wouldn't the overall qpid-proton source package also need to include a copy of https://github.com/zeromq/pyzmq/blob/master/COPYING.BSD somewhere? > Allow setup.py to bundle qpid-proton > > > Key: PROTON-885 > URL: https://issues.apache.org/jira/browse/PROTON-885 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Flavio Percoco >Assignee: Ken Giusti > Attachments: 0001-Allow-setup.py-for-bundling-proton.patch > > > Allow setup.py for bundling proton > > As of now, it's not possible to install python-qpid-proton if > libqpid-proton is not present in the system. To be more precises, it's > possible to build python-qpid-proton using cmake, upload it and beg to > the gods of OPs that the required (and correct) shared library will be > present in the system. > > This patch adds to python-qpid-proton the ability to download, build and > install qpid-proton if the required version is not present in the > system. It does this by checking - using pkg-config - whether the > required version is installed and if not, it goes to downloading the > package from the official apache source and builds it using cmake. > > As nasty as it sounds, this process is not strange in the Python > community. Very famous - and way more used - libraries like PyZMQ (from > which this work took lots of inspiration) do this already in a fairly > more complex way. > > This first step is quite simple, it checks, downloads and builds using > the standard tools. It's enabled just for linux and it does not use > fancy flags. Future enhancements could take care of improving the > implementation and extending it to support other systems. -- 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-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] [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] [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] [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] [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-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-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] [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] [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] [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] [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 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] [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] [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-tabpanel&focusedCommentId=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] [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-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-tabpanel&focusedCommentId=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-490) [proton-c] Python binding fails to link with Python 3 libraries
[ https://issues.apache.org/jira/browse/PROTON-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans reassigned PROTON-490: Assignee: Dominic Evans > [proton-c] Python binding fails to link with Python 3 libraries > --- > > Key: PROTON-490 > URL: https://issues.apache.org/jira/browse/PROTON-490 > Project: Qpid Proton > Issue Type: New Feature > Components: python-binding >Affects Versions: 0.6 >Reporter: Ken Giusti >Assignee: Dominic Evans > Attachments: 47_proton-490_fix_cproton.i.patch, > 47_proton-490_fix_import_statements_mllib_init.patch, > 47_proton-490_fix_mllib_dom.patch, 47_proton-490_fix_mllib_parsers.patch, > 47_proton-490_fix_mllib_transforms.py.patch, > 47_proton-490_fix_print_encodings.h.py.patch, > 47_proton-490_fix_print_protocol.h.py.patch, > 47_proton-490_fix_proton_init.patch > > > Attempting to link the Swig generated python bindings against the Python 3 > development libraries produces unresolved symbol errors: > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function `_wrap_pn_bytes': > pythonPYTHON_wrap.c:(.text+0xa567): undefined reference to > `PyString_FromStringAndSize' > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function > `_wrap_pn_bytes_dup': > pythonPYTHON_wrap.c:(.text+0xa701): undefined reference to > `PyString_FromStringAndSize' > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function > `_wrap_pn_message_get_user_id': > pythonPYTHON_wrap.c:(.text+0x1e827): undefined reference to > `PyString_FromStringAndSize' > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function > `_wrap_pn_data_get_decimal128': > pythonPYTHON_wrap.c:(.text+0x31450): undefined reference to > `PyString_FromStringAndSize' > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o: In function > `_wrap_pn_data_get_uuid': > pythonPYTHON_wrap.c:(.text+0x31559): undefined reference to > `PyString_FromStringAndSize' > CMakeFiles/_cproton.dir/pythonPYTHON_wrap.c.o:pythonPYTHON_wrap.c:(.text+0x31664): > more undefined references to `PyString_FromStringAndSize' follow > collect2: error: ld returned 1 exit status > This is due to a name change in the Python 3 API: > http://docs.python.org/2/c-api/string.html?highlight=pystring_fromstring#PyString_FromStringAndSize > http://docs.python.org/2/howto/cporting.html#conditional-compilation > The wrapper C code in proton-c/bindings/python/python.i needs to be updated > to support the Python 3 API. > -- 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] [Resolved] (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 resolved PROTON-737. -- Resolution: Fixed Fix Version/s: 0.9 > [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] [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] [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-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-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] [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] [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] [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] [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] [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-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] [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] [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-763) proton-c: pn_messenger_stop closes all links (detach w/ close=true) regardless of TTL / expiry
Dominic Evans created PROTON-763: Summary: 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 timeout>0 Patch available at: https://gist.github.com/dnwe/844d0b21ef9e757f584 -- 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 timeout>0 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 timeout>0 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 timeout>0 > Patch available at: > https://gist.github.com/dnwe/844d0b21ef9e757f584b -- 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-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-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] [Created] (PROTON-758) proton-c: assertion failure when SASL fails (PN_SASL_FAIL)
Dominic Evans created PROTON-758: Summary: 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 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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 updated PROTON-757: - Attachment: 0001-Don-t-trace-transport-errors-unless-PN_TRACE-set.patch patch attached > [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 > 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] [Created] (PROTON-757) [PATCH] proton-c: transport errors are output to stderr in 0.8 onwards
Dominic Evans created PROTON-757: Summary: [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 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] [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-tabpanel&focusedCommentId=14224422#comment-14224422 ] Dominic Evans commented on PROTON-752: -- So I can see that this might be a useful thing to add to the gem, as it does allow a user to trivially pass an event loop-style block to a messenger and to have it all executing asynchronously in a separate Thread. However, in your example of passing in a pre-created messenger object and/or returning the messenger object from the receive_and_call method, there is no locking around the messenger object? Messenger isn't thread-safe itself, so with ruby's Thread wakeup semantics it would be quite easy to start hitting race conditions when you allow the user to interact with messenger on multiple Threads in this way. So I think there is more work to do here to make this a robust feature. However, I still think that this patch is really about adding a new method that exposes the 'passive messenger' functionality in an easily-consumable way, which sounds like a useful thing to have but it doesn't seem to address this JIRA issue which is specifically: "As a Ruby >=1.9.x user, I expect to be able to call Messenger's blocking calls in a way that blocks my current Thread until the call I/O completes, but doesn't lock all Ruby Threads in the process". > 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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=14219564#comment-14219564 ] Dominic Evans commented on PROTON-752: -- Yeah I similarly didn't see any built in support for this. In any case you wouldn't want to just blanket enable it for all methods in all scenarios because there is some additional overhead in unlocking and re locking the GIL. Either through some swig template annotation or a hand written extra ./ext/ module to allow us to call any Cproton method, but with GIL unlocking surrounding it are the only options that come to mind. > 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 > > 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] [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-tabpanel&focusedCommentId=14218434#comment-14218434 ] Dominic Evans commented on PROTON-752: -- No I mean whenever a Cproton call won't return inmediately. For example, a blocking messenger.receive. At the moment we keep the GIL locked during that call until it completes. So in a multithreaded Ruby application, no other threads can make progress until that returns. > 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 > > 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] [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] [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-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] [Created] (PROTON-748) [PATCH] ruby: user doesn't have access to set settlement modes or messenger flags
Dominic Evans created PROTON-748: Summary: [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 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] [Created] (PROTON-743) [PATCH] ruby: user doesn't have access to clear messenger error object
Dominic Evans created PROTON-743: Summary: [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 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] [Updated] (PROTON-739) [PATCH] ruby: update messenger#subscribe to accept TTL
[ https://issues.apache.org/jira/browse/PROTON-739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-739: - Attachment: 0001-ruby-update-messenger-subscribe-to-accept-TTL.patch > [PATCH] ruby: update messenger#subscribe to accept TTL > -- > > Key: PROTON-739 > URL: https://issues.apache.org/jira/browse/PROTON-739 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.8 >Reporter: Dominic Evans > Attachments: 0001-ruby-update-messenger-subscribe-to-accept-TTL.patch > > > patch attached > allow messenger.rb to supply a TTL on subscribes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-739) [PATCH] ruby: update messenger#subscribe to accept TTL
Dominic Evans created PROTON-739: Summary: [PATCH] ruby: update messenger#subscribe to accept TTL Key: PROTON-739 URL: https://issues.apache.org/jira/browse/PROTON-739 Project: Qpid Proton Issue Type: Bug Components: ruby-binding Affects Versions: 0.8 Reporter: Dominic Evans patch attached allow messenger.rb to supply a TTL on subscribes -- 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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=14200052#comment-14200052
]
Dominic Evans commented on PROTON-736:
--
[~mcpierce] tested and confirmed working as desired, thanks for these
incidentally, yard (the extended rdoc that is used for rubygems.org's
documentation pages) does have an `@deprecated` annotation that you can use.
See https://gist.github.com/chetan/1827484 for a cheatsheet
> 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,
> 0002-PROTON-736-Only-encode-Ruby-strings-as-UTF-8-if-it-s.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-736) ruby: unable to send binary data?
[
https://issues.apache.org/jira/browse/PROTON-736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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] [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] [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] [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-tabpanel&focusedCommentId=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: 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-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] [Commented] (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:comment-tabpanel&focusedCommentId=14140480#comment-14140480
]
Dominic Evans commented on PROTON-576:
--
A small bit of improvement with that optimization, I'll attach a refreshed
patch.
{code:title=# Results|borderStyle=solid}
Benchmark Mode Samples Mean Mean
errorUnits
t.TestStringType.testUsingPatchedProtonthrpt40967.616
0.033 ops/ms
t.TestStringType.testUsingProton07 thrpt40968.947
0.079 ops/ms
{code}
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=14140439#comment-14140439
]
Dominic Evans commented on PROTON-576:
--
[~gemmellr] not sure what machine I ran the previous benchmarks on, but here's
the results from my desktop just now comparing a vanilla qpid-proton-0.7 with
one that has had my patch applied:
{code:title=# Results|borderStyle=solid}
Benchmark Mode Samples Mean Mean
errorUnits
t.TestStringType.testUsingPatchedProtonthrpt40967.270
0.031 ops/ms
t.TestStringType.testUsingProton07 thrpt40969.196
0.015 ops/ms
{code}
As you can see there is a small drop in ~2 ops/ms, but the performance is still
reasonably close to what it was before, and I'm not sure we can really consider
a benchmark of the previously incomplete UTF-8 parser as being a valid
performance comparison anyway :)
I could slightly optimise the isSurrogatePair checking to only call
string.charAt(i+1) if the current char is a highSurrogate value. I'll see if
that brings us any closer.
> 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-682) proton-c: a call to pn_messenger_stop can get into an infinite loop if the remote connection is severed
[ https://issues.apache.org/jira/browse/PROTON-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-682: - Attachment: 36_socket_hangup_fix_selector.h.patch 36_socket_hangup_fix_selector.c.patch 36_socket_hangup_fix_messenger.c.patch Proposed fix attached. > 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 > Attachments: 36_socket_hangup_fix_messenger.c.patch, > 36_socket_hangup_fix_selector.c.patch, 36_socket_hangup_fix_selector.h.patch > > > 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] [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] [Closed] (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 closed PROTON-610. > 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 >Assignee: Andrew Stitcher > Fix For: 0.8 > > 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.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] [Closed] (PROTON-575) proton-j: LoggingProtocolTracer used by FrameWriter cannot be overridden
[ https://issues.apache.org/jira/browse/PROTON-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans closed PROTON-575. > proton-j: LoggingProtocolTracer used by FrameWriter cannot be overridden > > > Key: PROTON-575 > URL: https://issues.apache.org/jira/browse/PROTON-575 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: 0.7 >Reporter: Dominic Evans >Assignee: Rafael H. Schloming > Attachments: 01_allow_access_to_protocolTracer_in_TransportImpl.patch > > > Currently, the default protocol tracer is passed into FrameWriter in the > TransportImpl constructor, and any subsequent call to > TransportImpl#setProtocolTracer() doesn't cause the one in FrameWriter to be > updated. -- 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] [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-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 closed PROTON-681. > 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] [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-tabpanel&focusedCommentId=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] [Updated] (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 updated PROTON-681: - Attachment: 33_pni_map_ensure_bug_fix_object.c.patch > 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] [Created] (PROTON-681) proton-c: pni_map_ensure infinite loop if `load = map->load_factor`
Dominic Evans created PROTON-681: Summary: 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] [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] [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-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] [Created] (PROTON-680) proton-c: Messenger doesn't provide a way of obtaining link or delivery information
Dominic Evans created PROTON-680: Summary: 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 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-679) proton-c: add a "manual" link credit mode to Messenger
[ https://issues.apache.org/jira/browse/PROTON-679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-679: - Attachment: 28_manual_link_management_messenger.c.patch > proton-c: add a "manual" link credit mode to Messenger > -- > > Key: PROTON-679 > URL: https://issues.apache.org/jira/browse/PROTON-679 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7 >Reporter: Dominic Evans > Attachments: 28_manual_link_management_messenger.c.patch > > > Add a manual link credit mode to Messenger. When 'LINK_CREDIT_MANUAL' mode is > used, Messenger does not try to track link credit or flow more link credit. > This is considered the responsibility of the > application code using Messenger. > Patch attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-679) proton-c: add a "manual" link credit mode to Messenger
Dominic Evans created PROTON-679: Summary: proton-c: add a "manual" link credit mode to Messenger Key: PROTON-679 URL: https://issues.apache.org/jira/browse/PROTON-679 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.7 Reporter: Dominic Evans Add a manual link credit mode to Messenger. When 'LINK_CREDIT_MANUAL' mode is used, Messenger does not try to track link credit or flow more link credit. This is considered the responsibility of the application code using Messenger. 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] [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] [Created] (PROTON-677) proton-c: transport incorrectly detaches all links with closed=true by default
Dominic Evans created PROTON-677: Summary: 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] [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] [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] [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-676) proton-c: transport layer SSL failures not propagated back to Messenger in pni_connection_readable
[ https://issues.apache.org/jira/browse/PROTON-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominic Evans updated PROTON-676: - Attachment: 24_ssl_transport_failure_fix_messenger.c.patch > 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-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-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-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-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-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-tabpanel&focusedCommentId=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)
