[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14515035#comment-14515035 ] ASF subversion and git services commented on PROTON-490: Commit d31100aae5b8e539111fc65a13f1bc8b782c787e in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=d31100a ] PROTON-490: covert python examples using 2to3 [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: Ken Giusti 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] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14515034#comment-14515034 ] ASF subversion and git services commented on PROTON-334: Commit f05810e95908d6614c4ef9694234329d05af7384 in qpid-proton's branch refs/heads/kgiusti-python3 from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f05810e ] PROTON-334: MBED mods breaks windows (no stdint.h) builds. SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-344) Need Ruby version of msgr-send/msgr-recv tools
[ https://issues.apache.org/jira/browse/PROTON-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14515033#comment-14515033 ] ASF subversion and git services commented on PROTON-344: Commit 2f1a98991fafe5ef7f1bbe09dc8d8ead2b1119b5 in qpid-proton's branch refs/heads/kgiusti-python3 from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=2f1a989 ] PROTON-344: Fix header file documentation for new sasl API Need Ruby version of msgr-send/msgr-recv tools -- Key: PROTON-344 URL: https://issues.apache.org/jira/browse/PROTON-344 Project: Qpid Proton Issue Type: Task Components: proton-c Affects Versions: 0.4 Reporter: Ken Giusti Assignee: Ken Giusti A ruby variant of msgr-send/recv traffic generators should be added to the soak tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fixes for Mac OS X
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/23#issuecomment-96820535 @rhs readily reproducible, [output from 20 runs](https://gist.github.com/dnwe/76c504f2a3067b32b904) and [python trace bz2](https://dl.dropboxusercontent.com/u/951543/trace.log.bz2) from a single run of the four tests --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (PROTON-790) Use git tag for release (rather than branch)
[ https://issues.apache.org/jira/browse/PROTON-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-790. Resolution: Fixed Use git tag for release (rather than branch) Key: PROTON-790 URL: https://issues.apache.org/jira/browse/PROTON-790 Project: Qpid Proton Issue Type: Improvement Components: release Affects Versions: 0.9 Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor I think it would make sense to use git tags to indicate the versions of releases including alphas and betas. So instead of having branch with a single change on it we should use a tag to indicate a release. This would also allow the branching structure and the releases to be independent. As an example the recent 0.9-alpha-1 could be a tag on a 0.9-release branch. Or it could just be a tag on a one change branch (to change the version). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-790) Use git tag for release (rather than branch)
[ https://issues.apache.org/jira/browse/PROTON-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-790: --- Fix Version/s: 0.9 Use git tag for release (rather than branch) Key: PROTON-790 URL: https://issues.apache.org/jira/browse/PROTON-790 Project: Qpid Proton Issue Type: Improvement Components: release Affects Versions: 0.9 Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor Fix For: 0.9 I think it would make sense to use git tags to indicate the versions of releases including alphas and betas. So instead of having branch with a single change on it we should use a tag to indicate a release. This would also allow the branching structure and the releases to be independent. As an example the recent 0.9-alpha-1 could be a tag on a 0.9-release branch. Or it could just be a tag on a one change branch (to change the version). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514059#comment-14514059 ] Gordon Sim commented on PROTON-858: --- As it turns out the use of the addressable region for entries that don't actually map there is *intended* and is a technique known as coalesced hashing. The error then is on the delete algorithm. unbalanced maps can get corrupted - Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical Fix For: 0.9.1 I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: candidate commits for 0.9.1
On 04/27/2015 01:14 PM, Rafael Schloming wrote: I also added PROTON-858 as a release blocker. I've been trying to get a fix proposal together for that. I'll post it for review as soon as I'm reasonably confident, still seeing some issues at present (not 100% sure they are related, but am assuming so).
Re: candidate commits for 0.9.1
On 27 April 2015 at 13:44, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 27 April 2015 at 13:23, Dominic Evans dominic.ev...@uk.ibm.com wrote: -Robbie Gemmell robbie.gemm...@gmail.com wrote: - I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-c ategorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I'd suggest you also pull in the following commits from that list: Python (+Examples) == 4653cdc Some sphinx based documentation of the python reactive api, including a tutorial to accompany the examples. 65aa64c fixed exception handling for events occuring during reactor shutdown 5bf533c PROTON-846: check whether connection is valid README etc == b532cf2 NO-JIRA: README improvements 1aa7bce NO-JIRA: rename README -- README.md c1a6de2 NO-JIRA: some additional README improvements 425c008 NO-JIRA: update README filename in CMakeLists Cheers, Dom Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Or, as I meant to say before Firefox stutter-scrolled an extra step and I clicked the wrong thing, Ok, I'll pick them in.
Re: candidate commits for 0.9.1
I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. Robbie On 25 April 2015 at 21:10, Robbie Gemmell robbie.gemm...@gmail.com wrote: New 0.9.x branch created, against the actual 0.9 tag this time. I have updated the JIRAs for the all the commits included so far to add the 0.9.1 fix version. If you want any commits included, either git cherry-pick -x them to the branch yourself or reply with the SHAs. Output of git cherry -v 0.9.x master after the first pass including commits for proton-j and 1 for proton-c: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1.txt Robbie On 24 April 2015 at 16:54, Robbie Gemmell robbie.gemm...@gmail.com wrote: Ok ignore all that for now. Andrew has noted a problem with the branch. I seemingly had a stale set of tags and an old 0.9 branch, so when I thought I was branching from the 0.9 tag I was actually not, but rather the 0.9-rc3 tag (which in my case happened to be the same as 0.9, but in an up to date checkout is not). All the relevant commits are there, but its not based on the right thing so I'll delete the branch and redo it over the weekend. Robbie On 24 April 2015 at 16:42, Robbie Gemmell robbie.gemm...@gmail.com wrote: I branched 0.9.x from the 0.9 tag and cherry picked the commits I mentioned earlier. I have added a 0.9.1 version in JIRA, though I havent yet updated the JIRAs for the commits which had one, I'll get that over the weekend. Here is an updated output from git-cherry of master agaisnt 0.9.x, for any remaining commits people might want included. Note that several of them are for the Go bits which werent in 0.9 and so those arent really applicable here, I just havent gone through the list to remove them. - 97ca1441ab656e54c666a4ac736836ada29900d2 NO-JIRA: lack of ssl support should not prevent Container being used - bc2b630eb969710b04a861797567ab2dc368020a NO-JIRA: fix documentation build - 36e32d2309bb0a96e63e9874758de8906a22ec69 add missing NOTICE file + 0816badb2361af12403c10768a38fd5794c5b84a PROTON-827: go binding - unmarshal all basic types. + 3f64ad7998b0d42bbefe672f08110893d96a94c9 NO-JIRA: minor cleanups for issues uncovered by Coverity Scan. - a3b8bb1805f5ffc24c487fd039ce47797a458437 NO-JIRA: Add missing import for SSLUnavailable in reactor.py + 8235ba1f1da41e67c284b866777b28118e4691d8 NO-JIRA: add a simple broker against which intermediated examples can be run + 4653cdc6fddb311d9805c6839ef7f0d1f718442f Some sphinx based documentation of the python reactive api, including a tutorial to accompany the examples. + 7e42628edb5c7d6cadc5fad1d5299aed15e11d38 PROTON-827: Marshal and unmarshal all basic types and reflect.Value + faf925c4afe02da2dced7a6592586b575ceea2ec PROTON-827: Marshal/unmarshal maps and lists. + 695f8e5b96c75640bcf10fb12252a0130b70d0a0 PROTON-827: go binding - send.go, listen.go examples with implementation stubs. - f8ca35f3e007b99e0a5365e154e067840adcefb0 PROTON-838: proton-hawtdispatch cannot connect with SSL - e31df015a79d791e62caf9bef3f29bdfd77042ef PROTON-839: Proton 0.9 RC 2 blocker - proton_tests.utils.SyncRequestResponseTest.test_request_response fail - 7b9b516d445ab9e86a0313709c77218d901435b1 PROTON-834: further UTF-8 encoder fixes + fac7c86c8bc818ea845d6426fd85095a189522d6 NO-JIRA: Measure size of encoded data. + 51ddf8a7cc8c0b93c6d6f0c19ffa49ba7c52c2a0 PROTON-827: Removed go examples. + dfbd744f2db59ce5ec5316d9739aea83c7f9c96d NO-JIRA: Removed gem dependency on driver.h + f32643492ba6763d46caccc59752ce1fb64ced9e PROTON-582: Added in missing is_float method to Perl bindings. + a73b8f4d0cb37365570121664033e6c654507170 NO-JIRA: Fix how gemspec generates extension + 94e92428109bc72eb49c4b68bf2a2f6402e16883 NO-JIRA: Fix install of Perl bindings + 973bad033ba3a1b700ab80ab4edee209ab81f05a NO-JIRA: Restore data position when measuring size of encoded data. + 262009958d45823791b8c41619d59df7a2128a35 NO-JIRA: Added json dependency to Ruby gemspec. + df2cd6c0cb19beb4d74690581005f9cb662cb856 Fixed a very minor spelling mistake. Please enter the commit message for your changes. Lines starting + 65aa64c0e3ce88e119b0a4bf416fc2b924cf5bfb fixed exception handling for events occuring during reactor shutdown - ea9ca783cd7e7516f37f23b661ae27ba326b128b NO-JIRA: export.sh creates pax-based tar - 938f4cb8c2e31c2bcc20fba7d973214ee38d650a fixed release.sh to work on tags -
Re: Messenger race condition on Android?
On Mon, Apr 20, 2015 at 8:12 PM, Adam Wynne awy...@gmail.com wrote: Hi Rafael, My answers to your questions are below... On Fri, Apr 17, 2015 at 8:33 AM Rafael Schloming-3 [via Qpid] ml-node+s2158936n7623117...@n2.nabble.com wrote: On Fri, Apr 17, 2015 at 8:09 AM, Adam Wynne [hidden email] http:///user/SendEmail.jtp?type=nodenode=7623117i=0 wrote: Sorry for the cross-post but I didn't get any hits on the user list and I now think this could be a bug. I think I am seeing a race condition with Messenger on Android only: When I do the typical put/send sequence in a Thread started from an Android Activity, the message is not received by a subscribed peer. If I kill the Activity, the peer will complain that the connection is broken. So it seems that the connection is being made but the data is not sent. Here is an example code snippet: Messenger messenger = Messenger.Factory.create(); // do other things like create a message messenger.put(msg) // Thread.sleep(200) messenger.send() However when I uncomment the sleep statement above, the message is received without any problem. The message is also received if I attempt to debug to see what is happening in put(). I noticed that put() does not simply add the message to a queue, it also uses nio methods to do some encoding of the message. I'm wondering if since it is not blocking, is there some encoding method happening while the send() is being processed, causing the message to be lost. We also noticed that there is a big CPU usage (up to 40%) spike during the put/send process, which seems extreme for just a tcp send. Hi Adam, Apologies in advance for the barrage of questions, but some additional information would be helpful. What version of the code are you working with? I first tried with 0.9, then I built the latest from source and had the same results each time Is your thread a long running thread or does it terminate shortly after the code you have posted? The thread is long running What exactly is receiving the message at the other end of the connection? I have tried 2 subscribers with the same results: one in android and one on a macbook. I get the same results on mac. Does a similar thread arrangement reproduce the issue outside of Android, and if so would it be possible to post a reproducer? No, I couldn't reproduce in a standard JVM. Do you want me to post the android app? That would certainly be helpful. --Rafael
[jira] [Updated] (PROTON-858) unbalanced maps can get corrupted
[ https://issues.apache.org/jira/browse/PROTON-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming updated PROTON-858: --- Fix Version/s: 0.9.1 unbalanced maps can get corrupted - Key: PROTON-858 URL: https://issues.apache.org/jira/browse/PROTON-858 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: Gordon Sim Priority: Critical Fix For: 0.9.1 I came across an issue caused by proton's inability to find a delivery for the id specified in a disposition it received, although the delivery with that id did indeed exist. On further analysis, it appears that maps that are not well balanced can get corrupted, such that the lookup function fails, even when the map 'contains' an entry with the required key. When adding an entry whose key maps to the same addressable index in the map as an existing entry, a free entry is taken from the end of the list and linked to that existing entry. However if all the entries outside the addressable range are used - and since addressable = 0.86*capacity, there are actually not that many of those - then a free entry from the addressable range is used for a key that does not map to that index. This can then lead to a situation where the deletion of an entry causes another to become unfindable. (Detailed example: assume capacity is 16, i.e. first 13 entries (indices 0 to 12) are addressable, last three (indices 13, 14 and 15) are not. Add value a with key 1, value b with key 2, value c with key 3. These take the first three addressable entries respectively. Now add items that map to those same addressable indexes, e.g. a2 with key 14, b2 with key 15, c2 with key 16. The three free non-addressable entries at the end are used for these i.e. indices 15, 14 and 13 respectively, and they are linked to the first three entries (at indices 1, 2 and 3 respectively). Now add d with key 4, which takes the 4th addressable index, then add d2 with key 17, which maps to the same addressable index. We take the next free entry which is at index 12 - *inside* the addressable range - set the key to 10, value to d2 and link it to the entry at index 4. Now delete key 17, which is at index 15. Then add value n with key 12. Index 12 is already taken by d2, so we use the newly vacated entry at index15 and link that to the end of d2 at index 12. Now we delete key 20 at index 12. Its the middle link in a chain of three so we join the previous entry - d at index 4 to the next entry n at index 15. Now you can't find n by its key 12). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: candidate commits for 0.9.1
On 27 April 2015 at 13:14, Rafael Schloming r...@alum.mit.edu wrote: This one should definitely go in: Ok, I'll pick it in. + aa5ea2b62fd5680bc2a36bee14f72e037d8cc276 close the transport when the selector reports an error I also added PROTON-858 as a release blocker. --Rafael On Mon, Apr 27, 2015 at 8:07 AM, Gordon Sim g...@redhat.com wrote: On 04/27/2015 12:46 PM, Robbie Gemmell wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I think all the commits under 'Python (+Examples)' can be included for 0.9.1.
Re: candidate commits for 0.9.1
On 04/27/2015 12:46 PM, Robbie Gemmell wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I think all the commits under 'Python (+Examples)' can be included for 0.9.1.
Re: candidate commits for 0.9.1
This one should definitely go in: + aa5ea2b62fd5680bc2a36bee14f72e037d8cc276 close the transport when the selector reports an error I also added PROTON-858 as a release blocker. --Rafael On Mon, Apr 27, 2015 at 8:07 AM, Gordon Sim g...@redhat.com wrote: On 04/27/2015 12:46 PM, Robbie Gemmell wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I think all the commits under 'Python (+Examples)' can be included for 0.9.1.
Re: candidate commits for 0.9.1
-Robbie Gemmell robbie.gemm...@gmail.com wrote: - I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-c ategorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I'd suggest you also pull in the following commits from that list: Python (+Examples) == 4653cdc Some sphinx based documentation of the python reactive api, including a tutorial to accompany the examples. 65aa64c fixed exception handling for events occuring during reactor shutdown 5bf533c PROTON-846: check whether connection is valid README etc == b532cf2 NO-JIRA: README improvements 1aa7bce NO-JIRA: rename README -- README.md c1a6de2 NO-JIRA: some additional README improvements 425c008 NO-JIRA: update README filename in CMakeLists Cheers, Dom Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: candidate commits for 0.9.1
On 27 April 2015 at 13:07, Gordon Sim g...@redhat.com wrote: On 04/27/2015 12:46 PM, Robbie Gemmell wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I think all the commits under 'Python (+Examples)' can be included for 0.9.1. Ok, I'll pick them in.
Re: candidate commits for 0.9.1
On 27 April 2015 at 13:23, Dominic Evans dominic.ev...@uk.ibm.com wrote: -Robbie Gemmell robbie.gemm...@gmail.com wrote: - I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-c ategorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. I'd suggest you also pull in the following commits from that list: Python (+Examples) == 4653cdc Some sphinx based documentation of the python reactive api, including a tutorial to accompany the examples. 65aa64c fixed exception handling for events occuring during reactor shutdown 5bf533c PROTON-846: check whether connection is valid README etc == b532cf2 NO-JIRA: README improvements 1aa7bce NO-JIRA: rename README -- README.md c1a6de2 NO-JIRA: some additional README improvements 425c008 NO-JIRA: update README filename in CMakeLists Cheers, Dom Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
[jira] [Created] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
Adrian Preston created PROTON-869: - Summary: [proton-c] should be straightforward to associate handlers with acceptors Key: PROTON-869 URL: https://issues.apache.org/jira/browse/PROTON-869 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Currently it is only possible to associate a handler with an acceptor by casting it to pn_selectable_t. This could be broken by a future change to the implementation of pn_acceptor_t. Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Error handling in the proton-c reactor (and how it might relate to a Java port)
Thanks Rafael, This is really helpful. I'll have a look through the Python reactor code (kicking myself for not thinking to do this earlier...) and try and get the Java port to handle errors in a similar way. Regards - Adrian On Fri, Apr 24, 2015 at 11:06 PM, Rafael Schloming r...@alum.mit.edu wrote: Hi Adrian, See inline for answers... On Thu, Apr 23, 2015 at 12:17 PM, Adrian Preston prest...@uk.ibm.com wrote: Hello all, While porting the proton-c reactor to Java, I've found a few error paths that I wasn't sure how best to handle. I have some ideas (see below), but if this stuff is already written down somewhere - feel free to suitably admonish me (and then point me towards it...) 1) When an error occurs while the reactor is servicing a connection: the connection is closed with a transport error. This is already implemented by various functions in reactor/connection.c (e.g. pni_handle_bound, to pick one at random), so I expect Java following suit shouldn't be too contentious. Yes 2) When an error occurs while the reactor is accepting a connection: a PN_SELECTABLE_ERROR event is delivered to the acceptor's collector. This might necessitate a new pn_acceptor_attachments function to associate a handler with an acceptor (casting to selectable strikes me as something that might break in the future...). Aside: should it be possible to associate a pn_error (Java Throwable?) with an event, so that it is possible to report the underlying cause for a PN_SELECTABLE_ERROR? A pn_acceptor_attachments function makes sense to me. Regarding your other question. In general I've been trying to stick to having each event reference only a single object, and also reference state in the object model rather than carry state itself, so I might consider adding an accessor to pn_selectable_t to store/extract error information instead of storing it on the event. 3) In the Java reactor it is possible for an unchecked (derived from RuntimeException) exception to be thrown from a handler. Delivering a PN_SELECTABLE_ERROR to the selectable seems like the wrong thing to do (because the handler that threw the exception might not be associated with a selectable, or the exception could be thrown while handling PN_SELECTABLE_ERROR). Logging the exception then swallowing it seems likely to result in situations where the reactor appears to have hung. So the best I've come up with is that the Java equivalent of pn_reactor_process throws an exception - but then I'm not clear what state the reactor should be left in? Permanently failing, by throwing a ReactorBorked exception from any future pn_reactor_process invocation? Also, if this happens should the reactor be responsible for reclaiming the resources used by its children (e.g. closing their sockets)? The python wrapper of the reactor has a similar situation since python code can also throw runtime exceptions. From my experience coding against the API, you definitely want to know sooner rather than later exactly what has gone wrong. It can be easy to miss errors that scroll by in a log, so I would definitely not attempt to continue executing automatically. That said I would try not to leave the reactor in a permanently borked state either since you might want the option to fire events related to shutdown after an error. What I've done in python is roughly the following. I catch and save any exceptions that occur during dispatch of the current event to its handlers. When that event has been dispatched to all handlers, I throw an exception (it's anonymous currently, but it should probably be some sort of DispatchException) from Reactor.process() that references any exceptions that occurred during dispatch of that event. This by default results in the reactor failing fast when an exception occurs, but also leave things in a state where the user can easily log the exception and call process again if they wish to continue. Regarding reclaiming resources, I don't attempt to close sockets or anything like that since for my use cases when the reactor fails the whole process exits. In C this will happen when the reactor is freed, but obviously in python and/or java you would be depending on GC to make that happen and it might not be soon enough, so it may make sense to add a method that would explicitly do that sort of cleanup. --Rafael Regards - Adrian Adrian Preston, IBM WebSphere MQ Development - Hursley - MQ Light -Rafael Schloming r...@alum.mit.edu wrote: - To: proton@qpid.apache.org proton@qpid.apache.org From: Rafael Schloming r...@alum.mit.edu Date: 04/24/2015 11:06AM Subject: Re: Error handling in the proton-c reactor (and how it might relate to a Java port) Hi Adrian, See inline for answers... On Thu, Apr 23, 2015 at 12:17 PM, Adrian Preston prest...@uk.ibm.com wrote: Hello all, While porting the proton-c reactor to Java, I've found a
[jira] [Updated] (PROTON-869) [proton-c] should be straightforward to associate handlers with acceptors
[ https://issues.apache.org/jira/browse/PROTON-869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Preston updated PROTON-869: -- Attachment: proton-869.patch This patch adds a new pn_acceptor_attachments function, which (indirectly) allows a handler to be associated with a acceptor without casting. It also checks for an invalid socket being returned by the acceptor's call to pn_accept and generates a PN_SELECTABLE_ERROR event. [proton-c] should be straightforward to associate handlers with acceptors - Key: PROTON-869 URL: https://issues.apache.org/jira/browse/PROTON-869 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor Attachments: proton-869.patch Currently it is only possible to associate a handler with an acceptor by casting it to pn_selectable_t. This could be broken by a future change to the implementation of pn_acceptor_t. Related: the acceptor implementation does not generate a PN_SELECTABLE_ERROR event if the act of accepting a socket connection fails. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Cristoloveanu updated PROTON-870: - Summary: none_sasl.c should use pn_strdup (was: nona_sasl.c should use pn_strdup) none_sasl.c should use pn_strdup Key: PROTON-870 URL: https://issues.apache.org/jira/browse/PROTON-870 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Dan Cristoloveanu Priority: Trivial Original Estimate: 2h Remaining Estimate: 2h none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-870) nona_sasl.c should use pn_strdup
Dan Cristoloveanu created PROTON-870: Summary: nona_sasl.c should use pn_strdup Key: PROTON-870 URL: https://issues.apache.org/jira/browse/PROTON-870 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Dan Cristoloveanu Priority: Trivial none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fix none_sasl.c to use pn_strdup instead...
GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/24 Fix none_sasl.c to use pn_strdup instead of strdup (PROTON-870) none_sasl.c should use pn_strdup. none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. Thanks, /Dan You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton NoneSASL Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/24.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #24 commit 300ffc4246f0007a70b40954e29fbbe44796ad74 Author: dcristoloveanu dcri...@microsoft.com Date: 2015-04-28T00:44:05Z Fix none_sasl.c to use pn_strdup instead of strdup --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516068#comment-14516068 ] ASF GitHub Bot commented on PROTON-870: --- GitHub user dcristoloveanu opened a pull request: https://github.com/apache/qpid-proton/pull/24 Fix none_sasl.c to use pn_strdup instead of strdup (PROTON-870) none_sasl.c should use pn_strdup. none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. Thanks, /Dan You can merge this pull request into a Git repository by running: $ git pull https://github.com/dcristoloveanu/qpid-proton NoneSASL Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/24.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #24 commit 300ffc4246f0007a70b40954e29fbbe44796ad74 Author: dcristoloveanu dcri...@microsoft.com Date: 2015-04-28T00:44:05Z Fix none_sasl.c to use pn_strdup instead of strdup none_sasl.c should use pn_strdup Key: PROTON-870 URL: https://issues.apache.org/jira/browse/PROTON-870 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Dan Cristoloveanu Priority: Trivial Original Estimate: 2h Remaining Estimate: 2h none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fix none_sasl.c to use pn_strdup instead...
Github user astitcher commented on the pull request: https://github.com/apache/qpid-proton/pull/24#issuecomment-96902826 Oops --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516305#comment-14516305 ] ASF subversion and git services commented on PROTON-870: Commit 73d8ff9af3e2745020157bca9338ea29848bb358 in qpid-proton's branch refs/heads/master from [~dcristoloveanu] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=73d8ff9 ] PROTON-870: Fix none_sasl.c to use pn_strdup instead of strdup This closes #24 none_sasl.c should use pn_strdup Key: PROTON-870 URL: https://issues.apache.org/jira/browse/PROTON-870 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Dan Cristoloveanu Priority: Trivial Original Estimate: 2h Remaining Estimate: 2h none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fix none_sasl.c to use pn_strdup instead...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/24 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-870) none_sasl.c should use pn_strdup
[ https://issues.apache.org/jira/browse/PROTON-870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516306#comment-14516306 ] ASF GitHub Bot commented on PROTON-870: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/24 none_sasl.c should use pn_strdup Key: PROTON-870 URL: https://issues.apache.org/jira/browse/PROTON-870 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.10 Reporter: Dan Cristoloveanu Priority: Trivial Original Estimate: 2h Remaining Estimate: 2h none_sasl.c uses strdup, but strdup is not part of C99 and subsequently does not exist on some platforms. Instead pn_strdup should be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fixes for Mac OS X
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/23#issuecomment-96717495 @rhs I believe you originally wrote the SelectableMessengerTest, could you take a look at change and confirm if this is an acceptable change in the test behaviour? It wasn't clear to me if you were intending to validate that a single call to Pump#pump would always result in at least one message being flowed into incoming? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14514312#comment-14514312 ] ASF subversion and git services commented on PROTON-334: Commit f05810e95908d6614c4ef9694234329d05af7384 in qpid-proton's branch refs/heads/master from [~chug] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f05810e ] PROTON-334: MBED mods breaks windows (no stdint.h) builds. SASL Implementation for Proton C Key: PROTON-334 URL: https://issues.apache.org/jira/browse/PROTON-334 Project: Qpid Proton Issue Type: Wish Components: proton-c Reporter: Ted Ross Assignee: Andrew Stitcher It would be desirable to have the ability to use a plug-in module for SASL in Proton. The following implementations could then be developed: 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL 2) A Cyrus-Sasl based plugin for Linux 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Fixes for Mac OS X
GitHub user dnwe opened a pull request: https://github.com/apache/qpid-proton/pull/23 Fixes for Mac OS X 1. default to building universal binaries so the various language bindings can link against the system libraries out of the box 2. small fix to SelectableMessengerTest as it was regularly failing on Mac builds. You can merge this pull request into a Git repository by running: $ git pull https://github.com/dnwe/qpid-proton fixes-for-mac Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/23.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #23 commit 2a120b8d401c6931f46757717e9883e4f8c41ebb Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-27T14:41:55Z NO-JIRA: default to universal binaries on Mac OS X The system-installed Perl, Python etc. are all built as universal binaries on Mac and so we need to build libqpid-proton to similarly contain both architectures. This allows the bindings to link successfully. commit c07377c780cb70153e5c1f9136e69fcbbbcfa5a2 Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-27T15:28:33Z NO-JIRA: fix SelectableMessengerTest on Mac The SelectableMessengerTest was failing intermittently on Mac builds, Modify the test slightly to be more resilient. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: candidate commits for 0.9.1
Ok I have now cherry picked the commits mentioned earlier by Gordon, Rafael, and Dominic. The current categorised list of commits is now at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass2-categorised.txt The bare git cherry -v 0.9.x master output is at: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass2.txt Robbie On 27 April 2015 at 12:46, Robbie Gemmell robbie.gemm...@gmail.com wrote: I have gone through the git cherry output and categorised the remaining commits from master that dont have a direct equivalent on the 0.9.x branch, splitting according to what they update i.e. mainly by language. I listed some as excluded based on what they are for, e.g the 0.10 sasl work, and any Go-only changes (because the Go bits were not in 0.9). http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1-categorised.txt I'd like to get the 0.9.1 release out this week, which would mean starting a vote tomorrow, so if you want specific commits included then please shout now. Robbie On 25 April 2015 at 21:10, Robbie Gemmell robbie.gemm...@gmail.com wrote: New 0.9.x branch created, against the actual 0.9 tag this time. I have updated the JIRAs for the all the commits included so far to add the 0.9.1 fix version. If you want any commits included, either git cherry-pick -x them to the branch yourself or reply with the SHAs. Output of git cherry -v 0.9.x master after the first pass including commits for proton-j and 1 for proton-c: http://people.apache.org/~robbie/qpid/proton/0.9.1/git-cherry-pass1.txt Robbie On 24 April 2015 at 16:54, Robbie Gemmell robbie.gemm...@gmail.com wrote: Ok ignore all that for now. Andrew has noted a problem with the branch. I seemingly had a stale set of tags and an old 0.9 branch, so when I thought I was branching from the 0.9 tag I was actually not, but rather the 0.9-rc3 tag (which in my case happened to be the same as 0.9, but in an up to date checkout is not). All the relevant commits are there, but its not based on the right thing so I'll delete the branch and redo it over the weekend. Robbie On 24 April 2015 at 16:42, Robbie Gemmell robbie.gemm...@gmail.com wrote: I branched 0.9.x from the 0.9 tag and cherry picked the commits I mentioned earlier. I have added a 0.9.1 version in JIRA, though I havent yet updated the JIRAs for the commits which had one, I'll get that over the weekend. Here is an updated output from git-cherry of master agaisnt 0.9.x, for any remaining commits people might want included. Note that several of them are for the Go bits which werent in 0.9 and so those arent really applicable here, I just havent gone through the list to remove them. - 97ca1441ab656e54c666a4ac736836ada29900d2 NO-JIRA: lack of ssl support should not prevent Container being used - bc2b630eb969710b04a861797567ab2dc368020a NO-JIRA: fix documentation build - 36e32d2309bb0a96e63e9874758de8906a22ec69 add missing NOTICE file + 0816badb2361af12403c10768a38fd5794c5b84a PROTON-827: go binding - unmarshal all basic types. + 3f64ad7998b0d42bbefe672f08110893d96a94c9 NO-JIRA: minor cleanups for issues uncovered by Coverity Scan. - a3b8bb1805f5ffc24c487fd039ce47797a458437 NO-JIRA: Add missing import for SSLUnavailable in reactor.py + 8235ba1f1da41e67c284b866777b28118e4691d8 NO-JIRA: add a simple broker against which intermediated examples can be run + 4653cdc6fddb311d9805c6839ef7f0d1f718442f Some sphinx based documentation of the python reactive api, including a tutorial to accompany the examples. + 7e42628edb5c7d6cadc5fad1d5299aed15e11d38 PROTON-827: Marshal and unmarshal all basic types and reflect.Value + faf925c4afe02da2dced7a6592586b575ceea2ec PROTON-827: Marshal/unmarshal maps and lists. + 695f8e5b96c75640bcf10fb12252a0130b70d0a0 PROTON-827: go binding - send.go, listen.go examples with implementation stubs. - f8ca35f3e007b99e0a5365e154e067840adcefb0 PROTON-838: proton-hawtdispatch cannot connect with SSL - e31df015a79d791e62caf9bef3f29bdfd77042ef PROTON-839: Proton 0.9 RC 2 blocker - proton_tests.utils.SyncRequestResponseTest.test_request_response fail - 7b9b516d445ab9e86a0313709c77218d901435b1 PROTON-834: further UTF-8 encoder fixes + fac7c86c8bc818ea845d6426fd85095a189522d6 NO-JIRA: Measure size of encoded data. + 51ddf8a7cc8c0b93c6d6f0c19ffa49ba7c52c2a0 PROTON-827: Removed go examples. + dfbd744f2db59ce5ec5316d9739aea83c7f9c96d NO-JIRA: Removed gem dependency on driver.h + f32643492ba6763d46caccc59752ce1fb64ced9e PROTON-582: Added in missing is_float method to Perl bindings. + a73b8f4d0cb37365570121664033e6c654507170 NO-JIRA: Fix how gemspec generates extension + 94e92428109bc72eb49c4b68bf2a2f6402e16883 NO-JIRA: Fix install of Perl bindings + 973bad033ba3a1b700ab80ab4edee209ab81f05a NO-JIRA: Restore data position when measuring size of encoded data. + 262009958d45823791b8c41619d59df7a2128a35 NO-JIRA: Added json dependency to Ruby gemspec. +
[jira] [Commented] (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:comment-tabpanelfocusedCommentId=14514321#comment-14514321 ] ASF subversion and git services commented on PROTON-490: Commit 9380ed938fafa9e19cb0d3514725427d8243041b in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9380ed9 ] PROTON-490: avoid decoding text if method calls fail [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: Ken Giusti 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)
[GitHub] qpid-proton pull request: Fixes for Mac OS X
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/23#issuecomment-96722982 fixes-for-mac:  --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: Fixes for Mac OS X
Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/23#issuecomment-96734626 I'm a little puzzled as to why the test change would be necessary. Pump has been written to keep looping until there is no I/O left to perform for any of its messengers. Given that the receiving messenger has issued credit, and the sending messenger has posted messages for transfer, I think this is probably somehow indicative of a real bug somewhere (possibly in some of the test framework code). How easy is it to reproduce this on a mac? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Topic Subscriptions using Proton's C API
HEY ALL! Where are the C demos for simple send/receive using the new reactor API? I would like to point at them but can't find them... On Sun, 2015-04-26 at 07:41 -0700, dylan25 wrote: Hello, My name is Dylan. I am a software engineering intern that is working on MOM. I am currently working on a C-based AMQP 1.0 program that implement Publish/Subscribe functionality with topics. I have been looking at Qpid Proton's C AMQP 1.0 API for this, although I have been unable to find the functionality for topic-based subscriptions. I am quite a novice to MOM and I was wondering if anybody might be able to point me in the direction of documentation and/or sample programs for Proton's topic-based subscriptions? Thank you, any and all help is appreciated! Hi Dylan, Proton is a protocol engine that provides the ability to send and receive messages to arbitrary AMQP 1.0 endpoints. It does not have topic-based subscriptions (or other common messaging features like message queuing) built in. Proton clients can talk to message brokers that do provide such services. For example you can download the Qpid C++ or Java broker from qpid.apache.org and use the clients in proton/examples (or write your own) to send/receive on topics provided by the brokers. Just put an address in your proton messages that matches the address of a topic or queue on the broker - the address syntax depends on the broker you use. The python examples provide a good set of toys to play with. If you are ambitious you can build features like topics on top of proton. It is not hard to build a simple demo broker or topic server. I don't think there is one in C but examples/python/broker.py will give you an idea in python. The proton API is undergoing some changes. The python examples use an event-based API which is the new trend. This is also possible in C, the examples in examples/engine/c are the closest fit, although I think they can be simplified based on recent improvements in proton. The messenger examples are for the older style API. Cheers, Alan.
