Re: 0.8 release prep
On 22. 09. 14 19:57, Andrew Stitcher wrote: On Sun, 2014-09-21 at 23:43 +0200, Bozo Dragojevic wrote: PROTON-660: Fix openssl.c build on windows Are you planning to do this work yourself? If so please take into account my last comments on this bug. I'd work on it myself except that I don't currently have the correct set up. If you can detail the set up (and it's not hard to set up) I'd do it. Yep, learning by doing :) What's the most convenient way for the review process? Patches to the mailing list? links to github commits? apache's reviewboard? My guess is the later, except it's the most unfamiliar process to me :) If you want to set up, just build openssl from source (which requires ActivePerl iirc) and just make sure to install in one of the locations that cmake looks at. PROTON-691: allow proton to be built with add_subdirectory How important is this? The current way to integrate a proton build with another build is via the install directory, this seems to work well. It's not super important, just very convenient. Is there a specific scenario when you can't run 2 builds with a common install prefix? (This would actually probably make more sense added to the jira itself) The idea behind this is to get one build system (esp handy for VS and Xcode) We started with two build systems with the intermediate install step. Since there always seem to be at least one proton bugfix waiting to go upstream, we keep track of a patched proton tree as a git submodule. For development cycle when one is working on said fixes it's really convenient to be able to run our tests in-tree quickly, skipping the install step. When proton stabilizes, all this becomes irrelevant. I know such approach does not really scale because cmake's symbols are not namespaced. So, if there is a more proper cmake-istic approach how to achieve a similar workflow I'd be happy to adapt in that direction. Bozzo
[jira] [Commented] (PROTON-660) Fix openssl.c build on windows
[
https://issues.apache.org/jira/browse/PROTON-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14144563#comment-14144563
]
Bozo Dragojevic commented on PROTON-660:
{quote}
I don't understand the need to undefine symbols - the windows header file that
defines them shouldn't be included in any include chain, and if it is then
that is a problem. The only files in our code base that should include windows
(or more broadly platform specific headers) is platform.c and c files that are
only compiled on specific platforms. None of the .h files should (need to)
include windows headers.
{quote}
I've got the the bottom of this, and have a cleaner solution, still. The root
cause is that openssl/ssl.h includes
openssl/x509.h that already has the exact same undefine. But that includes
happens before it includes openssl/dtls1.h which pulls in winsock.h that
re-defines the symbols. End effect is, openssl on windows works only if
winsock.h is explicitly included before any openssl header is included -- which
I guess is why only some people see this, some not.
So the real solution is a oneliner in ../platform.h to include winsock.h on
windows. wdyt?
{quote}
The use of strncasecmp() should be abstracted the same way we've abstracted
snprintf() - by adding a definition to platform.h using some implementation
probably in platform.c or util.c
{quote}
I've noticed pn_i_eq_nocase() and just followed suit with pn_i_eq_n_nocase().
So, iiuc, that part is OK, I should just leave openssl.c call strncasecmp() and
add to platform.h a
{code}
#define strncasecmp(a,b) (!pn_i_eq_nocase(a,b))
{code}
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] [Commented] (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:comment-tabpanelfocusedCommentId=14144695#comment-14144695 ] ASF subversion and git services commented on PROTON-676: Commit 1626980 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1626980 ] PROTON-676: patch from dominic for setter for SSL peer authentication mode 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] [Assigned] (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 ] Rafael H. Schloming reassigned PROTON-675: -- Assignee: Rafael H. Schloming 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 Assignee: Rafael H. Schloming Fix For: 0.8 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] [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-tabpanelfocusedCommentId=14144779#comment-14144779
]
ASF subversion and git services commented on PROTON-576:
Commit 1627019 from [~gemmellr] in branch 'proton/trunk'
[ https://svn.apache.org/r1627019 ]
PROTON-576: update String UTF-8 encoding to handle high range unicode
characters / surrogate pairs
Applied patch from Dominic Evans with modifications by Rob Godfrey
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, PROTON-576.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-687) Memory corruption in proton-test
[ https://issues.apache.org/jira/browse/PROTON-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14144783#comment-14144783 ] Ken Giusti commented on PROTON-687: --- Thinking a bit more on this - I think my original patch was not the right solution. AFAIKT, the decrement that occurs when the delivery is removed from the settled/unsettled list corresponds to the original allocation of the delivery (remember, on allocation, the delivery's refcount is initialized to 1). So an additional increment of the reference count when the delivery is placed on the settled/unsettled list _should_ not be required. What appears to be happening is the python Connection is being deleted, which causes all children - including links and their deliveries - to be deleted. This causes the python Delivery's _release() to be called which settles the C delivery *but does not clear the _dlv field which references the now deallocated C delivery object*. In addition __del__ does not check if _dlv has been cleared before passing it to pn_delivery_set_context(). I think a proper fix would be: diff --git a/proton-c/bindings/python/proton.py b/proton-c/bindings/python/proton.py index ee3701c..ce24321 100644 --- a/proton-c/bindings/python/proton.py +++ b/proton-c/bindings/python/proton.py @@ -2897,12 +2897,14 @@ class Delivery(object): self.link._deliveries.add(self) def __del__(self): -pn_delivery_set_context(self._dlv, pn_py2void(None)) +self._release() def _release(self): Release the underlying C Engine resource. if self._dlv: + pn_delivery_set_context(self._dlv, pn_py2void(None)) pn_delivery_settle(self._dlv) + self._dlv = None @property def tag(self): Thoughts? Memory corruption in proton-test Key: PROTON-687 URL: https://issues.apache.org/jira/browse/PROTON-687 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Cliff Jansen Assignee: Rafael H. Schloming Priority: Blocker Attachments: segv.patch proton-test will fail with memory violations. Deallocated memory is accessed, usually with benign results but less often on Windows. The attached crude patch allows the bug to be discovered on Linux as well. It is not clear to me if the problem is with the swig wrapper, or whether this just exposes a reference counting bug in proton-c. -- 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 ] Ted Ross updated PROTON-548: Fix Version/s: 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.8 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] [Commented] (PROTON-693) Python Url class to wrap C function pni_parse_url
[ https://issues.apache.org/jira/browse/PROTON-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145002#comment-14145002 ] ASF subversion and git services commented on PROTON-693: Commit 1627086 from [~aconway] in branch 'proton/trunk' [ https://svn.apache.org/r1627086 ] PROTON-693: Implement C-API wrappers in Java for jython, clean up Url implementation. - Java implementation of fake C API for Jython SWIG wrappers based on messenger.impl.Address. - Minor extensions to Address.java - Minor change to Address.java to be consistent with C parser on one corner case: - is url(/foo) a host called /foo or an empty host and a path foo - fixed Java parser to agree with C - path foo - Rename getters from url_* to url_get_*. - Use pn_string_t formatting functions to build URL string. Python Url class to wrap C function pni_parse_url - Key: PROTON-693 URL: https://issues.apache.org/jira/browse/PROTON-693 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.8 Add a Url class to the python binding that wraps the C function pni_url_parse. Also added unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-687) Memory corruption in proton-test
[ https://issues.apache.org/jira/browse/PROTON-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-687: - Assignee: Ken Giusti (was: Rafael H. Schloming) Memory corruption in proton-test Key: PROTON-687 URL: https://issues.apache.org/jira/browse/PROTON-687 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Cliff Jansen Assignee: Ken Giusti Priority: Blocker Attachments: segv.patch proton-test will fail with memory violations. Deallocated memory is accessed, usually with benign results but less often on Windows. The attached crude patch allows the bug to be discovered on Linux as well. It is not clear to me if the problem is with the swig wrapper, or whether this just exposes a reference counting bug in proton-c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-687) Memory corruption in proton-test
[ https://issues.apache.org/jira/browse/PROTON-687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145030#comment-14145030 ] ASF subversion and git services commented on PROTON-687: Commit 1627090 from [~kgiusti] in branch 'proton/trunk' [ https://svn.apache.org/r1627090 ] PROTON-687: clear reference to C object when delivery is released. Memory corruption in proton-test Key: PROTON-687 URL: https://issues.apache.org/jira/browse/PROTON-687 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Cliff Jansen Assignee: Ken Giusti Priority: Blocker Attachments: segv.patch proton-test will fail with memory violations. Deallocated memory is accessed, usually with benign results but less often on Windows. The attached crude patch allows the bug to be discovered on Linux as well. It is not clear to me if the problem is with the swig wrapper, or whether this just exposes a reference counting bug in proton-c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-687) Memory corruption in proton-test
[ https://issues.apache.org/jira/browse/PROTON-687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-687. --- Resolution: Fixed Fix Version/s: 0.8 Applied change as described in last comment. Memory corruption in proton-test Key: PROTON-687 URL: https://issues.apache.org/jira/browse/PROTON-687 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.8 Reporter: Cliff Jansen Assignee: Ken Giusti Priority: Blocker Fix For: 0.8 Attachments: segv.patch proton-test will fail with memory violations. Deallocated memory is accessed, usually with benign results but less often on Windows. The attached crude patch allows the bug to be discovered on Linux as well. It is not clear to me if the problem is with the swig wrapper, or whether this just exposes a reference counting bug in proton-c. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: 0.8 release prep
This is definitely something that will need to get done eventually, but it isn't currently being worked on to my knowledge and is unlikely to be in 0.8 as a result. Patches are welcome though. Robbie On 18 September 2014 17:15, Fugitt, Jesse jfug...@informatica.com wrote: The missing functionality for idle timeout in Proton-J (JIRA PROTON-111) which exists in the C API would be nice at some point so it can be leveraged by future releases of ActiveMQ and other projects where keep alive behavior is needed by proton/AMQP clients. Thanks, Jesse -Original Message- From: Rafael Schloming [mailto:r...@alum.mit.edu] Sent: Thursday, September 18, 2014 9:55 AM To: proton@qpid.apache.org Subject: 0.8 release prep Hi Everyone, I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in order to triage any remaining issues. If there are any particular issues that you feel strongly should be included in 0.8, please follow up on this thread and bring them to my attention. --Rafael
Intro to proton
Hello, Our company is currently evaluating some AMQP technologies and one of the ones we are interested in is proton. We are currently having some trouble getting a connection from the proton client to an Apache Qpid instance. The Qpid client connects with no problems, but when we use proton we get the following error: Calling pn_messenger_send() [003224B0]:ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a' [003224B0]:ERROR[-2] SASL header mismatch: '' CONNECTION ERROR connection aborted (remote) Any help/guidance you can provide to get us past this would be greatly appreciated. Thanks, Jake O'Hara | Software Architect | Design Development Aristocrat Technologies, Inc. tel 702 270 1217 | fax 702 270 1136 email jake.oh...@aristocrat-inc.commailto:jake.oh...@aristocrat-inc.com | web www.aristocratgaming.comhttp://www.aristocratgaming.com/ P Please consider the environment before printing this e-mail IMPORTANT CONFIDENTIALITY NOTICE: This E-mail (including any documents referred to in, or attached, to this E-mail) may contain information that is personal, confidential or the subject of copyright or other proprietary rights in favor of Aristocrat, its affiliates or third parties. This E-mail is intended only for the named addressee. Any privacy, confidence, copyright or other proprietary rights in favor of Aristocrat, its affiliates or third parties, is not lost because this E-mail was sent to you by mistake. If you received this E-mail by mistake you should: (i) not copy, disclose, distribute or otherwise use it, or its contents, without the consent of Aristocrat or the owner of the relevant rights; (ii) let us know of the mistake by reply E-mail or by telephone (US 1-877-274-9661, or AU +61 2 9013 6000); and (iii) delete it from your system and destroy all copies. Any personal information contained in this E-mail must be handled in accordance with applicable privacy laws. Electronic and internet communications can be interfered with or affected by viruses and other defects. As a result, such communications may not be successfully received or, if received, may cause interference with the integrity of receiving, processing or related systems (including hardware, software and data or information on, or using, that hardware or software). Aristocrat gives no assurances in relation to these matters. If you have any doubts about the veracity or integrity of any electronic communication we appear to have sent you, please call (US 1-877-274-9661, or AU +61 2 9013 6000) for clarification.
[jira] [Assigned] (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 ] Rafael H. Schloming reassigned PROTON-677: -- Assignee: Rafael H. Schloming 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 Assignee: Rafael H. Schloming 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] [Commented] (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:comment-tabpanelfocusedCommentId=14145109#comment-14145109 ] ASF subversion and git services commented on PROTON-677: Commit 1627098 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1627098 ] PROTON-677: added support for detach 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 Assignee: Rafael H. Schloming Fix For: 0.8 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] [Resolved] (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 ] Rafael H. Schloming resolved PROTON-677. Resolution: Fixed Fix Version/s: 0.8 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 Assignee: Rafael H. Schloming Fix For: 0.8 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-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 ] Rafael H. Schloming updated PROTON-678: --- Assignee: Andrew Stitcher 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 Assignee: Andrew Stitcher 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)
Re: Intro to proton
Hi Jake, You are trying to run Proton (AMQP 1.0) against a broker that only talks AMQP 0-10. You need to make sure that the broker is loading the amqp.so module so it can support the 1.0 protocol. qpidd --load-module amqp.so If you are building the broker from source, you need to make sure Proton-c is installed or the build won't produce an amqp.so. If you need further clarification, please ask. -Ted On 09/23/2014 01:26 PM, O'Hara, Jake wrote: Hello, Our company is currently evaluating some AMQP technologies and one of the ones we are interested in is proton. We are currently having some trouble getting a connection from the proton client to an Apache Qpid instance. The Qpid client connects with no problems, but when we use proton we get the following error: Calling pn_messenger_send() [003224B0]:ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a' [003224B0]:ERROR[-2] SASL header mismatch: '' CONNECTION ERROR connection aborted (remote) Any help/guidance you can provide to get us past this would be greatly appreciated. Thanks, Jake O'Hara | Software Architect | Design Development Aristocrat Technologies, Inc. tel 702 270 1217 | fax 702 270 1136 email jake.oh...@aristocrat-inc.commailto:jake.oh...@aristocrat-inc.com | web www.aristocratgaming.comhttp://www.aristocratgaming.com/ P Please consider the environment before printing this e-mail IMPORTANT CONFIDENTIALITY NOTICE: This E-mail (including any documents referred to in, or attached, to this E-mail) may contain information that is personal, confidential or the subject of copyright or other proprietary rights in favor of Aristocrat, its affiliates or third parties. This E-mail is intended only for the named addressee. Any privacy, confidence, copyright or other proprietary rights in favor of Aristocrat, its affiliates or third parties, is not lost because this E-mail was sent to you by mistake. If you received this E-mail by mistake you should: (i) not copy, disclose, distribute or otherwise use it, or its contents, without the consent of Aristocrat or the owner of the relevant rights; (ii) let us know of the mistake by reply E-mail or by telephone (US 1-877-274-9661, or AU +61 2 9013 6000); and (iii) delete it from your system and destroy all copies. Any personal information contained in this E-mail must be handled in accordance with applicable privacy laws. Electronic and internet communications can be interfered with or affected by viruses and other defects. As a result, such communications may not be successfully received or, if received, may cause interference with the integrity of receiving, processing or related systems (including hardware, software and data or information on, or using, that hardware or software). Aristocrat gives no assurances in relation to these matters. If you have any doubts about the veracity or integrity of any electronic communication we appear to have sent you, please call (US 1-877-274-9661, or AU +61 2 9013 6000) for clarification.
[jira] [Assigned] (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 ] Rafael H. Schloming reassigned PROTON-679: -- Assignee: Rafael H. Schloming 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 Assignee: Rafael H. Schloming 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] [Resolved] (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 ] Rafael H. Schloming resolved PROTON-679. Resolution: Fixed Fix Version/s: 0.8 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 Assignee: Rafael H. Schloming Fix For: 0.8 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] [Assigned] (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 ] Rafael H. Schloming reassigned PROTON-680: -- Assignee: Rafael H. Schloming 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 Assignee: Rafael H. Schloming 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] [Commented] (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:comment-tabpanelfocusedCommentId=14145143#comment-14145143 ] ASF subversion and git services commented on PROTON-680: Commit 1627106 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1627106 ] PROTON-680: link and delivery accessors (patch from dominic) 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 Assignee: Rafael H. Schloming Fix For: 0.8 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] [Resolved] (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 ] Rafael H. Schloming resolved PROTON-680. Resolution: Fixed Fix Version/s: 0.8 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 Assignee: Rafael H. Schloming Fix For: 0.8 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] [Commented] (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:comment-tabpanelfocusedCommentId=14145133#comment-14145133 ] ASF subversion and git services commented on PROTON-679: Commit 1627102 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1627102 ] PROTON-679: patch from dominic for manual credit mode 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 Assignee: Rafael H. Schloming 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] [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 ] Rafael H. Schloming updated PROTON-682: --- Assignee: Andrew Stitcher 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 Assignee: Andrew Stitcher 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] [Commented] (PROTON-661) pn_message_save_* do not return correct message size when PN_OVERFLOW
[
https://issues.apache.org/jira/browse/PROTON-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145183#comment-14145183
]
Rafael H. Schloming commented on PROTON-661:
The patch seems to have lost its formatting. Can you attach it as a file?
pn_message_save_* do not return correct message size when PN_OVERFLOW
-
Key: PROTON-661
URL: https://issues.apache.org/jira/browse/PROTON-661
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.4, 0.5, 0.7
Environment: All plataforms
Reporter: Miguel da Rocha Correia Lima
Priority: Critical
Expected behavior:
When you use pn_message_save* functions API, you pass char *data and char
*size. If the size IS NOT enough to save mesage body text, this functions
return in char *size variable, the necessary buffer size and return
PN_OVERFLOW status.
Behavior observed:
The pn_message_save* functions API return PN_OVERFLOW status and DO NOT
return a correct value of necessary buffer.
Patch to fix expected behavior :
--cut
diff -Naur qpid-proton-0.7-ORIG/proton-c/src/message/message.c
qpid-proton-0.7-LDX/p
--- qpid-proton-0.7-ORIG/proton-c/src/message/message.c 2014-03-10
13:33:11.
+++ qpid-proton-0.7-LDX/proton-c/src/message/message.c 2014-09-04
23:31:44.9280
@@ -972,6 +972,7 @@
pn_data_error(msg-body));
if (scanned) {
if (bytes.size *size) {
+ *size = bytes.size;
return PN_OVERFLOW;
} else {
memcpy(data, bytes.start, bytes.size);
@@ -994,6 +995,7 @@
{
pn_bytes_t str = pn_data_get_bytes(msg-body);
if (str.size = *size) {
+ *size = str.size;
return PN_OVERFLOW;
} else {
memcpy(data, str.start, str.size);
--cut
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: 0.8 release prep
I'll take a look at the patch if you can resubmit it as a file. The patch in the comment has lost formatting. On Thu, Sep 18, 2014 at 11:15 AM, Miguel da Rocha Correia Lima mcorreial...@landix.com.br wrote: Hi Rafael, The PROTON-661 was useful for us. We are working with this patch without any error. We supose that it can be useful for others. Miguel da Rocha Correia Lima miguel at landix dot com dot br Em 18/09/2014 11:55, Rafael Schloming escreveu: Hi Everyone, I'd like to put out a 0.8 RC soon. I will be going through JIRA shortly in order to triage any remaining issues. If there are any particular issues that you feel strongly should be included in 0.8, please follow up on this thread and bring them to my attention. --Rafael
[jira] [Updated] (PROTON-661) pn_message_save_* do not return correct message size when PN_OVERFLOW
[
https://issues.apache.org/jira/browse/PROTON-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Miguel da Rocha Correia Lima updated PROTON-661:
Attachment: landix-ret-size-message-save.patch
Patch to return necessary buffer message size in pm_message_save* .
pn_message_save_* do not return correct message size when PN_OVERFLOW
-
Key: PROTON-661
URL: https://issues.apache.org/jira/browse/PROTON-661
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.4, 0.5, 0.7
Environment: All plataforms
Reporter: Miguel da Rocha Correia Lima
Priority: Critical
Attachments: landix-ret-size-message-save.patch
Expected behavior:
When you use pn_message_save* functions API, you pass char *data and char
*size. If the size IS NOT enough to save mesage body text, this functions
return in char *size variable, the necessary buffer size and return
PN_OVERFLOW status.
Behavior observed:
The pn_message_save* functions API return PN_OVERFLOW status and DO NOT
return a correct value of necessary buffer.
Patch to fix expected behavior :
--cut
diff -Naur qpid-proton-0.7-ORIG/proton-c/src/message/message.c
qpid-proton-0.7-LDX/p
--- qpid-proton-0.7-ORIG/proton-c/src/message/message.c 2014-03-10
13:33:11.
+++ qpid-proton-0.7-LDX/proton-c/src/message/message.c 2014-09-04
23:31:44.9280
@@ -972,6 +972,7 @@
pn_data_error(msg-body));
if (scanned) {
if (bytes.size *size) {
+ *size = bytes.size;
return PN_OVERFLOW;
} else {
memcpy(data, bytes.start, bytes.size);
@@ -994,6 +995,7 @@
{
pn_bytes_t str = pn_data_get_bytes(msg-body);
if (str.size = *size) {
+ *size = str.size;
return PN_OVERFLOW;
} else {
memcpy(data, str.start, str.size);
--cut
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-693) Python Url class to wrap C function pni_parse_url
[ https://issues.apache.org/jira/browse/PROTON-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145380#comment-14145380 ] ASF subversion and git services commented on PROTON-693: Commit 1627155 from [~aconway] in branch 'proton/trunk' [ https://svn.apache.org/r1627155 ] PROTON-693: Make pn_url_t a proper pn_class object, hashable comparable. Python Url class to wrap C function pni_parse_url - Key: PROTON-693 URL: https://issues.apache.org/jira/browse/PROTON-693 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.8 Add a Url class to the python binding that wraps the C function pni_url_parse. Also added unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-695) New URL code causing invalid reads/writes according to valgrind
[
https://issues.apache.org/jira/browse/PROTON-695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved PROTON-695.
Resolution: Fixed
Fix Version/s: 0.8
Damn, I was sure I'd get the fix in before you spotted that. Fixed by
r1627086 | PROTON-693: Implement C-API wrappers in Java for jython, clean up
Url implementation.
r1627155 | PROTON-693: Make pn_url_t a proper pn_class object, hashable
comparable.
New URL code causing invalid reads/writes according to valgrind
---
Key: PROTON-695
URL: https://issues.apache.org/jira/browse/PROTON-695
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.8
Reporter: Andrew Stitcher
Assignee: Alan Conway
Fix For: 0.8
Getting these messages from valgrinding the python tests:
{noformat}
proton_tests.url.UrlTest.testArgs
==18678==
Invalid write of size 1
==18678==at 0x4A092A3: strcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18678==by 0xF8C51AF: copy (url.c:33)
==18678==by 0xF8C5224: pn_url_parse (url.c:62)
==18678==by 0xF67DA2A: _wrap_pn_url_parse (cprotonPYTHON_wrap.c:22477)
==18678==by 0x3C1EEDDC2D: PyEval_EvalFrameEx (ceval.c:4098)
==18678==by 0x3C1EEDEBBC: PyEval_EvalCodeEx (ceval.c:3330)
==18678==by 0x3C1EE6DCEC: function_call (funcobject.c:526)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE58514: instancemethod_call (classobject.c:2602)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE9E8B6: slot_tp_init (typeobject.c:5692)
==18678==by 0x3C1EE9D61E: type_call (typeobject.c:745)
==18678== Address 0xb9a6179 is 0 bytes after a block of size 25 alloc'd
==18678==at 0x4A06409: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18678==by 0xF8C5191: copy (url.c:32)
==18678==by 0xF8C5224: pn_url_parse (url.c:62)
==18678==by 0xF67DA2A: _wrap_pn_url_parse (cprotonPYTHON_wrap.c:22477)
==18678==by 0x3C1EEDDC2D: PyEval_EvalFrameEx (ceval.c:4098)
==18678==by 0x3C1EEDEBBC: PyEval_EvalCodeEx (ceval.c:3330)
==18678==by 0x3C1EE6DCEC: function_call (funcobject.c:526)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE58514: instancemethod_call (classobject.c:2602)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE9E8B6: slot_tp_init (typeobject.c:5692)
==18678==by 0x3C1EE9D61E: type_call (typeobject.c:745)
==18678==
==18678== Invalid read of size 1
==18678==at 0x4A09244: strlen (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18678==by 0xF8C5189: copy (url.c:32)
==18678==by 0xF8C530D: pn_url_parse (url.c:69)
==18678==by 0xF67DA2A: _wrap_pn_url_parse (cprotonPYTHON_wrap.c:22477)
==18678==by 0x3C1EEDDC2D: PyEval_EvalFrameEx (ceval.c:4098)
==18678==by 0x3C1EEDEBBC: PyEval_EvalCodeEx (ceval.c:3330)
==18678==by 0x3C1EE6DCEC: function_call (funcobject.c:526)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE58514: instancemethod_call (classobject.c:2602)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE9E8B6: slot_tp_init (typeobject.c:5692)
==18678==by 0x3C1EE9D61E: type_call (typeobject.c:745)
==18678== Address 0xb9a6179 is 0 bytes after a block of size 25 alloc'd
==18678==at 0x4A06409: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18678==by 0xF8C5191: copy (url.c:32)
==18678==by 0xF8C5224: pn_url_parse (url.c:62)
==18678==by 0xF67DA2A: _wrap_pn_url_parse (cprotonPYTHON_wrap.c:22477)
==18678==by 0x3C1EEDDC2D: PyEval_EvalFrameEx (ceval.c:4098)
==18678==by 0x3C1EEDEBBC: PyEval_EvalCodeEx (ceval.c:3330)
==18678==by 0x3C1EE6DCEC: function_call (funcobject.c:526)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE58514: instancemethod_call (classobject.c:2602)
==18678==by 0x3C1EE49DA2: PyObject_Call (abstract.c:2529)
==18678==by 0x3C1EE9E8B6: slot_tp_init (typeobject.c:5692)
==18678==by 0x3C1EE9D61E: type_call (typeobject.c:745)
==18678==
==18678== Invalid read of size 1
==18678==at 0x4A09294: strcpy (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18678==by 0xF8C51AF: copy (url.c:33)
==18678==by 0xF8C530D: pn_url_parse (url.c:69)
==18678==by 0xF67DA2A: _wrap_pn_url_parse (cprotonPYTHON_wrap.c:22477)
==18678==by 0x3C1EEDDC2D: PyEval_EvalFrameEx (ceval.c:4098)
==18678==by 0x3C1EEDEBBC: PyEval_EvalCodeEx
[jira] [Resolved] (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 ] Andrew Stitcher resolved PROTON-678. Resolution: Cannot Reproduce 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 Assignee: Andrew Stitcher 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] [Commented] (PROTON-696) The header file usage needs some improvement
[ https://issues.apache.org/jira/browse/PROTON-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145905#comment-14145905 ] ASF subversion and git services commented on PROTON-696: Commit 1627219 from [~astitcher] in branch 'proton/trunk' [ https://svn.apache.org/r1627219 ] PROTON-696: Rearrange the header files: - Reduce transitive header inclusions - Remove proton/util.h and move its contents to src/util.h. All the defined symbols were internal. - Stop including with lines like #include ../blah.h as this isn't needed anymore. (Fixes windows breakage from PROTON-676) The header file usage needs some improvement Key: PROTON-696 URL: https://issues.apache.org/jira/browse/PROTON-696 Project: Qpid Proton Issue Type: Improvement Reporter: Andrew Stitcher Assignee: Andrew Stitcher There are a number of small header file problems with proton. * Some header files include too many other header files and so export too many symbols - this is especially problematic if they use platform header files. * Conversely some header files are not self contained and do not define all the symbols they use (by using the correct include files themselves) * There are symbols exported in the installed header files which are internal only symbols -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14145906#comment-14145906 ] ASF subversion and git services commented on PROTON-676: Commit 1627219 from [~astitcher] in branch 'proton/trunk' [ https://svn.apache.org/r1627219 ] PROTON-696: Rearrange the header files: - Reduce transitive header inclusions - Remove proton/util.h and move its contents to src/util.h. All the defined symbols were internal. - Stop including with lines like #include ../blah.h as this isn't needed anymore. (Fixes windows breakage from PROTON-676) 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] [Commented] (PROTON-693) Python Url class to wrap C function pni_parse_url
[ https://issues.apache.org/jira/browse/PROTON-693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14145932#comment-14145932 ] ASF subversion and git services commented on PROTON-693: Commit 1627222 from [~astitcher] in branch 'proton/trunk' [ https://svn.apache.org/r1627222 ] PROTON-693: Export pn_url... symbols as C not C++ Python Url class to wrap C function pni_parse_url - Key: PROTON-693 URL: https://issues.apache.org/jira/browse/PROTON-693 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.8 Add a Url class to the python binding that wraps the C function pni_url_parse. Also added unit tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
