candidate commits for 0.9.1
Hi folks, Running git-cherry against 0.9 and master to compare their history since divergence results in the following output. Lines starting with '-' already have equivalent commits in 0.9 from the RC stages, lines starting with '+' do not. I am going to begin going through these and cherry picking things to a 0.9.x branch today, currently aiming to include most of the changes to proton-j (excluding changes from the SASL work, and possibly some around Data size?), some changes to the release scripts, and also the proton-c commit for PROTON-850. For any other changes, you can either join in adding things to the branch or give me the commit ids. Robbie - 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 + 0b439c16e72560d575bce67e5a4300d1ea89ef52 PROTON-843: Java should match C for idle timeout + f937ccd04a99575cb44ec4108908d155e9f3a101 PROTON-844: police handle-max in proton-j + 836cf278a1c2aa6d8fafe90b4b253549782bcefb NO-JIRA: additional fix to proton-j UTF-8 + 677ea33fd6dfc362ab4272da394aa5944cc15637 NO-JIRA: fix erroneous getRemoteIdleTimeout() + b541ad08805e5567bfe8279650a674163c46cb8d https://issues.apache.org/jira/browse/PROTON-845 + 5bf533c2eeb3cd17f64e6b90748bc23960d4a185 PROTON-846: check whether connection is valid + 450b8ba5d061014de879c5fdd3c507a65003aca4 Small improvements to documentation based on feedback received + 3fd17dbc7960c55c32285846c13bed85e54a6293 NO-JIRA: Add missing #includes to session.h to make it compile stand-alone. + 6d90c02ef15119bbf99d07c60214b3753096fa30 NO-JIRA: Separated pn_message_data from pn_message_encode to extract message as a pn_data_t + 4a09c6a17f865df10f53fa61c8d2bc88d4627bb0 PROTON-334: SASL Implementation for Proton-C using Cyrus SASL + c7c26c649318436c7fc8b00b8c0a833b21037e75 NO-JIRA: Improved error reporting for overflow/underflow. + d6f1b8371d0dca82531b363f2a2ebdee55e56dfa PROTON-827: Initial work on Go language client for proton. + 8744409e21ab208009ed7003435d44438600fc93 PROTON-827: Fix typo in go/README.md + 828713eaba72d411ea121e58232c739219c37752 PROTON-827: go binding: examples for the concurrent Go API. + aa5ea2b62fd5680bc2a36bee14f72e037d8cc276 close the transport when the selector reports an error + 81085e348ce15c088a82a117e4892c760a57b9fe PROTON-490: futurize proton-c/bindings + 1e4b121d6fdbcfa5585416dfdca4430e042f52bf PROTON-854: remove sessions from the list when they are freed +
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new link attach for a link in the process of being detached
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14510759#comment-14510759 ] Robbie Gemmell commented on PROTON-853: --- The changes in this JIRA allow for rcv = session.reciever(foo) - rcv.open() - rcv.close() - rcv = session.reciever(foo) - rcv.open to work without having called free() on the link after it is closed. Upon inspection I dont believe it allows the same to occur for 'detach' rather than 'close', and the behaviour of that will return to what it was in 0.8 and prior, where free() must be called after the detach to ensure subsequent use of the link name works. As the behaviour in 0.9 was broken anyway (hence this JIRA) we think that is acceptable. This change will be incorporated into a '0.9.1' release with other critical bug fixes, with any more work around detach generally being better suited to a future larger release. [proton-j] the transport emitted a new link attach for a link in the process of being detached -- Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-853) [proton-j] the transport emitted a new attach frame for a link in the process of being closed
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated PROTON-853: -- Summary: [proton-j] the transport emitted a new attach frame for a link in the process of being closed (was: [proton-j] the transport emitted a new link attach for a link in the process of being detached) [proton-j] the transport emitted a new attach frame for a link in the process of being closed - Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- 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)
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
[GitHub] qpid-proton pull request: NO-JIRA: README improvements
GitHub user dnwe opened a pull request: https://github.com/apache/qpid-proton/pull/22 NO-JIRA: README improvements * remove out-of-date product information from the README and include the more current information from the website * add a new INSTALL file to contain the build and install instructions from the existing README * move all development and testing related info from that to the DEVELOPERS file * better explain how to run the various test suites and how they work across proton-c and proton-j in the developers file * other misc improvements across the contents of the files * rename DEVELOPERS and INSTALL to have .md suffixes for better rendering on GitHub * add a symlink from README -- README.md for better landing page rendering on GitHub You can merge this pull request into a Git repository by running: $ git pull https://github.com/dnwe/qpid-proton improve-readmes Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/22.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 #22 commit b532cf25756424c840047ad039b5c43eeb864046 Author: Dominic Evans dominic.ev...@uk.ibm.com Date: 2015-04-24T11:14:17Z NO-JIRA: README improvements * remove out-of-date product information from the README and include the more current information from the website * add a new INSTALL file to contain the build and install instructions from the existing README * move all development and testing related info from that to the DEVELOPERS file * better explain how to run the various test suites and how they work across proton-c and proton-j in the developers file * other misc improvements across the contents of the files * rename DEVELOPERS and INSTALL to have .md suffixes for better rendering on GitHub * add a symlink from README -- README.md for better landing page rendering on GitHub --- 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: NO-JIRA: README improvements
Github user rhs commented on the pull request: https://github.com/apache/qpid-proton/pull/22#issuecomment-95922186 +1 As a general note I think it's good to try to test changes to install/readme type stuff on people who aren't already intimately familiar with proton and all its various quirks. I wouldn't hold up merging this for that though. Nice work, BTW! It's great to see this sort of stuff get cleaned up! --- 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: NO-JIRA: README improvements
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/22 --- 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: NO-JIRA: README improvements
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/22#issuecomment-95931032 I've sent these off to be further reviewed by a few people round here to see if I can determine further improvements., Have merged them in as-is for now as I believe they're a decent first pass at improving what we currently had. @mcpierce fyi, this will require an update to the rpm qpid-proton.spec to account for the new file extension of `README.md` --- 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: [GitHub] qpid-proton pull request: NO-JIRA: README improvements
Make install tries to install README instead of README.md. On Fri, Apr 24, 2015 at 9:21 AM, dnwe g...@git.apache.org wrote: Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/22#issuecomment-95931032 I've sent these off to be further reviewed by a few people round here to see if I can determine further improvements., Have merged them in as-is for now as I believe they're a decent first pass at improving what we currently had. @mcpierce fyi, this will require an update to the rpm qpid-proton.spec to account for the new file extension of `README.md` --- 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] [Created] (PROTON-864) don't overload top bit of channel numbers
michael goulish created PROTON-864: -- Summary: don't overload top bit of channel numbers Key: PROTON-864 URL: https://issues.apache.org/jira/browse/PROTON-864 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.9 Reporter: michael goulish Assignee: michael goulish Code in transport.c, and a little in engine.c, looks at the topmost bit in channel numbers to decide if the channels are in use. This causes crashes when the number of channels in a single connection goes beyond 32767. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-865) C++ reactor client binding
Cliff Jansen created PROTON-865: --- Summary: C++ reactor client binding Key: PROTON-865 URL: https://issues.apache.org/jira/browse/PROTON-865 Project: Qpid Proton Issue Type: New Feature Environment: C++ Reporter: Cliff Jansen Assignee: Cliff Jansen This JIRA tracks initial work on a C++ binding to the Proton reactor event based model with an eye to providing an API very similar to the python client. As stated on the Proton list, the broad goals are: to make it easy to write simple programs natural to build out more complicated ones very similar API to the Python client lean and performant The initial introduction with accompanying HelloWorld can be found at https://github.com/apache/qpid-proton/pull/18 Ongoing work is proceeding in my github account in branch cpp-work https://github.com/cliffjansen/qpid-proton/tree/cpp-work commit 1453f57ca3f446450ef654505548f1947cb7a0f1 adds listener support, exceptions and a logging interface. The initial implementation will provide no thread safety guarantees, but the bone structure should allow that to be added later with no API change. I still hold out hope of eventually allowing multiple threads processing separate connections concurrently. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new attach frame for a link in the process of being closed
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511208#comment-14511208 ] ASF subversion and git services commented on PROTON-853: Commit 371e2adf33d17c9a55bbccdedd4c9ae42ecc6fc2 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=371e2ad ] PROTON-853: revert the change from PROTON-154, including the test since it doesnt actually fail without the change. This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5. (cherry picked from commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c) [proton-j] the transport emitted a new attach frame for a link in the process of being closed - Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511213#comment-14511213 ] ASF subversion and git services commented on PROTON-850: Commit acd1e1c9a582aaf190bb32ebc5bd9e590bd71930 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=acd1e1c ] PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab) inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-154) proton-j: link attach, detach, attach sequence on single session does not result in a new link for the 2nd attach
[
https://issues.apache.org/jira/browse/PROTON-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511209#comment-14511209
]
ASF subversion and git services commented on PROTON-154:
Commit 371e2adf33d17c9a55bbccdedd4c9ae42ecc6fc2 in qpid-proton's branch
refs/heads/0.9.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=371e2ad ]
PROTON-853: revert the change from PROTON-154, including the test since it
doesnt actually fail without the change.
This reverts commit 7d3063e7c488c97b9bad61e862d54b2b11dbc3d5.
(cherry picked from commit d2262bb7e2ead5b12ed2d4baf94cca6f06e0146c)
proton-j: link attach, detach, attach sequence on single session does not
result in a new link for the 2nd attach
-
Key: PROTON-154
URL: https://issues.apache.org/jira/browse/PROTON-154
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, proton-j
Reporter: Hiram Chirino
Assignee: Dominic Evans
Fix For: 0.9
Attachments: PROTON-154-test.patch, PROTON-154.patch
Protocol trace:
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | SENT: Attach{name='topic', handle=1, role=SENDER,
sndSettleMode=2, rcvSettleMode=0,
source=Source{address='topic://testJoramTopic', durable=2,
expiryPolicy=never, timeout=0, dynamic=false, dynamicNodeProperties=null,
distributionMode=copy, filter=null, defaultOutcome=null, outcomes=null,
capabilities=null}, 2target=Target{address='null', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=0, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
tcp://127.0.0.1:58348 | RECV: Flow{nextIncomingId=1, incomingWindow=2048,
nextOutgoingId=0, outgoingWindow=2048, handle=1, deliveryCount=0,
linkCredit=100, available=null, drain=false, echo=false, properties=null}
tcp://127.0.0.1:58348 | RECV: Detach{handle=1, closed=true, error=null}
tcp://127.0.0.1:58348 | SENT: Detach{handle=1, closed=false, error=null}
tcp://127.0.0.1:58348 | RECV: Attach{name='topic', handle=1, role=RECEIVER,
sndSettleMode=0, rcvSettleMode=0, source=null,
target=Target{address='644cf32c-d6c7-45eb-a8b7-3018d4c9594e', durable=0,
expiryPolicy=session-end, timeout=0, dynamic=false,
dynamicNodeProperties=null, capabilities=null}, unsettled=null,
incompleteUnsettled=false, initialDeliveryCount=null, maxMessageSize=null,
offeredCapabilities=null, desiredCapabilities=null, properties=null}
no link is produced on the second attach when you call:
protonConnection.linkHead(UNINITIALIZED_SET, INITIALIZED_SET);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new attach frame for a link in the process of being closed
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511210#comment-14511210 ] ASF subversion and git services commented on PROTON-853: Commit acd1e1c9a582aaf190bb32ebc5bd9e590bd71930 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=acd1e1c ] PROTON-853: add a test that catches the issue from PROTON-154 (and PROTON-850) (cherry picked from commit 252f5f0c1a3cb50edac7813eb233a37697e1f2ab) [proton-j] the transport emitted a new attach frame for a link in the process of being closed - Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- 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=14511416#comment-14511416 ] ASF subversion and git services commented on PROTON-344: Commit 2f1a98991fafe5ef7f1bbe09dc8d8ead2b1119b5 in qpid-proton's branch refs/heads/master 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)
[jira] [Commented] (PROTON-862) Proton using Cyrus SASL library is problematic because the library has global state
[ https://issues.apache.org/jira/browse/PROTON-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511864#comment-14511864 ] Rafael H. Schloming commented on PROTON-862: It strikes me that we could probably structure things such that the initialization problem is punted to the application. For example, we could by default use the same fallback code that is currently used when cyrus is not available. We can then provide an API for the application to tell us to start using cyrus instead of the fallback. This way the application can do the cyrus initialization however it chooses and then if/when the application has initialized cyrus, it can tell us to start using it. Proton using Cyrus SASL library is problematic because the library has global state --- Key: PROTON-862 URL: https://issues.apache.org/jira/browse/PROTON-862 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher The Cyrus SASL library is not 100% suitable for use in other libraries because it has global state and needs to be globally initialised before use as either a SASL client or SASL server. One requirement for this global initialisation seems to be to load the mechanism plugins. This global state is problematic because we cannot dictate what the linked in application and other libraries may do with Cyrus SASL themselves. In particular we currently use the sasl_server_init() call to set the basename for the config file that is used for the SASL settings. It is possible to work around this by passing in NULL instead of a name and so not changing whatever the application may have set. However we will then need to set the Cyrus SASL options manually by implementing the SASL_CB_GETOPT callback which returns the options set in the config file, so that we don't need Cyrus to do it for us. Even so we would still have to be setting the global callbacks to NULL in our initialisation, as there is no way to make Cyrus ignore the global callback initialisation - this implies that for correct interop no library (and probably no application either) can ever set these global callbacks, as they will have no way to ensure that some random library loaded in doesn't reset them! Another (perhaps better) alternative would be to port Proton to use another SASL library, which better respects being used in a library and has no global state. A good example of this would be libgsasl. However its API is significantly more complex to use, largely because it doesn't do the user authentication part itself and requires the application or dependant library to do it. So at this point this route would involve significant extra work, although might be long term more maintainable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-868) Make Pipelined ANONYMOUS authentication work with fallback SASL implementation
Andrew Stitcher created PROTON-868: -- Summary: Make Pipelined ANONYMOUS authentication work with fallback SASL implementation Key: PROTON-868 URL: https://issues.apache.org/jira/browse/PROTON-868 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.10 Reporter: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-866) Implement SASL external with TLS client authentication
[ https://issues.apache.org/jira/browse/PROTON-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511873#comment-14511873 ] Andrew Stitcher commented on PROTON-866: Amongst other things this will require getting the TLS authid out of the TLS/SSL layer. Implement SASL external with TLS client authentication -- Key: PROTON-866 URL: https://issues.apache.org/jira/browse/PROTON-866 Project: Qpid Proton Issue Type: Sub-task Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-857) reduce memory usage for the TransportSession link handle tracking
[ https://issues.apache.org/jira/browse/PROTON-857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511217#comment-14511217 ] ASF subversion and git services commented on PROTON-857: Commit aef2fafeeaecb2031d928099cfde0315120a241e in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=aef2faf ] PROTON-857: use maps to track handle usage, avoid pre-allocating large arrays we typically wont utilise fully Also reduces handle-max to 65535, giving 65536 usable handles like proton-c currently has. (cherry picked from commit 74e16dfe00f21621e8dbc27cea41ae12ad9a66c7) reduce memory usage for the TransportSession link handle tracking - Key: PROTON-857 URL: https://issues.apache.org/jira/browse/PROTON-857 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.10 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 Attachments: 0001-PROTON-857-use-maps-to-track-handle-usage-avoid-pre-.patch The TransportSession class currently maintains two 'maps' of [local|remote] handle-TransportLink using arrays of size handle-max + 1 (since we start from 0 when using handles, just like array indexes). The handle-max value used to be 1024 in proton-j but was recently changed to be 65536 in PROTON-844, allowing us to track 65537 handles. This change exposes the transports already somewhat inefficient storage of handles by requiring ~64x as much memory per open session, which in most cases wont use the extra capacity and indeed may often only need to use a single handle at a time (or worse, none, if a session isnt actually used for some weird reason). The handle tracking should be updated to use a HashMap, in similar fashion to how the session channel numbers are tracked by the transport. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-853) [proton-j] the transport emitted a new attach frame for a link in the process of being closed
[ https://issues.apache.org/jira/browse/PROTON-853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511214#comment-14511214 ] ASF subversion and git services commented on PROTON-853: Commit 7fa680794b7d78906129216471170dc7d720b156 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7fa6807 ] PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. This closes #21 (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b) [proton-j] the transport emitted a new attach frame for a link in the process of being closed - Key: PROTON-853 URL: https://issues.apache.org/jira/browse/PROTON-853 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.9 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.10 When upgrading to use 0.9 for the JMS client, we see some NPEs on the client as it tries processing the events being emitted by the connection. This was due to multiple link attach and detach frames arriving in the for the same consumer link. What appears to be happening is that while closing the consumer, after the client emits its detach frame proton then emits a new attach frame for the link, before the server responds to the original detach, even though the client made no attempt to recreate the consumer. It looks like the clients handling of a flow frame which arrived after it emitted the original detach meant that the link was modified, and the transport reacted by sending out a new attach. This appears to be due to a change made in 0.9 for PROTON-154. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-850) inconsistent state when reusing link name
[ https://issues.apache.org/jira/browse/PROTON-850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511215#comment-14511215 ] ASF subversion and git services commented on PROTON-850: Commit 7fa680794b7d78906129216471170dc7d720b156 in qpid-proton's branch refs/heads/0.9.x from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7fa6807 ] PROTON-853: dont return the cached links if they are already in the closed state, instead create a new object and ensure the old links also get freed. Also fixes similar behaviour as in PROTON-850. This closes #21 (cherry picked from commit f2d7d669155a2ca57606c9381f4f1720739be79b) inconsistent state when reusing link name - Key: PROTON-850 URL: https://issues.apache.org/jira/browse/PROTON-850 Project: Qpid Proton Issue Type: Bug Components: proton-c, python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.10 Attachments: PROTON_850.py If a link is closed, and a new link with the same name is created and opened, the attach received for the second link from the peer is applied to the old link. If the old link is freed after being closed, this is avoided, but I'm not sure that is possible via e.g. the python bindings. The root of the problem I think is that a handle is reused after the link is closed, whether freed or not, but when processing an incoming attach, it is the link name that is used to find the appropriate link, which iterates through all links until it matches one by name, which in this case is the old, closed link. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: candidate commits for 0.9.1
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 - 0b439c16e72560d575bce67e5a4300d1ea89ef52 PROTON-843: Java should match C for idle timeout - f937ccd04a99575cb44ec4108908d155e9f3a101 PROTON-844: police handle-max in proton-j - 836cf278a1c2aa6d8fafe90b4b253549782bcefb NO-JIRA: additional fix to proton-j UTF-8 - 677ea33fd6dfc362ab4272da394aa5944cc15637 NO-JIRA: fix erroneous getRemoteIdleTimeout() - b541ad08805e5567bfe8279650a674163c46cb8d https://issues.apache.org/jira/browse/PROTON-845 + 5bf533c2eeb3cd17f64e6b90748bc23960d4a185 PROTON-846: check whether connection is valid + 450b8ba5d061014de879c5fdd3c507a65003aca4 Small improvements to documentation based on feedback received + 3fd17dbc7960c55c32285846c13bed85e54a6293 NO-JIRA: Add missing #includes to session.h to make it compile stand-alone. + 6d90c02ef15119bbf99d07c60214b3753096fa30 NO-JIRA: Separated pn_message_data from pn_message_encode to extract message as a pn_data_t + 4a09c6a17f865df10f53fa61c8d2bc88d4627bb0 PROTON-334: SASL Implementation for Proton-C using Cyrus SASL + c7c26c649318436c7fc8b00b8c0a833b21037e75 NO-JIRA: Improved error reporting for overflow/underflow. + d6f1b8371d0dca82531b363f2a2ebdee55e56dfa PROTON-827: Initial work on Go language client for proton. +
[GitHub] qpid-proton pull request: Mbed minor changes and sasl mech
Github user dcristoloveanu commented on the pull request: https://github.com/apache/qpid-proton/pull/19#issuecomment-95988615 I think this can be merged in now, unless there's anything else that you think needs addressing. Thanks! /Dan --- 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
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 - 0b439c16e72560d575bce67e5a4300d1ea89ef52 PROTON-843: Java should match C for idle timeout - f937ccd04a99575cb44ec4108908d155e9f3a101 PROTON-844: police handle-max in proton-j - 836cf278a1c2aa6d8fafe90b4b253549782bcefb NO-JIRA: additional fix to proton-j UTF-8 - 677ea33fd6dfc362ab4272da394aa5944cc15637 NO-JIRA: fix erroneous getRemoteIdleTimeout() - b541ad08805e5567bfe8279650a674163c46cb8d https://issues.apache.org/jira/browse/PROTON-845 + 5bf533c2eeb3cd17f64e6b90748bc23960d4a185 PROTON-846: check whether connection is valid + 450b8ba5d061014de879c5fdd3c507a65003aca4 Small improvements to documentation based on feedback received + 3fd17dbc7960c55c32285846c13bed85e54a6293 NO-JIRA: Add missing #includes to session.h to make it compile stand-alone. + 6d90c02ef15119bbf99d07c60214b3753096fa30 NO-JIRA: Separated pn_message_data from pn_message_encode to extract message as a pn_data_t + 4a09c6a17f865df10f53fa61c8d2bc88d4627bb0 PROTON-334: SASL Implementation for Proton-C using Cyrus SASL + c7c26c649318436c7fc8b00b8c0a833b21037e75 NO-JIRA: Improved error reporting for overflow/underflow. + d6f1b8371d0dca82531b363f2a2ebdee55e56dfa PROTON-827: Initial work on Go language client for proton. + 8744409e21ab208009ed7003435d44438600fc93 PROTON-827: Fix typo in go/README.md + 828713eaba72d411ea121e58232c739219c37752 PROTON-827: go binding: examples for the concurrent Go API. + aa5ea2b62fd5680bc2a36bee14f72e037d8cc276 close the transport when the selector reports an error + 81085e348ce15c088a82a117e4892c760a57b9fe PROTON-490: futurize proton-c/bindings - 1e4b121d6fdbcfa5585416dfdca4430e042f52bf PROTON-854: remove sessions from the list when they are freed + 7cf0ababd4e59a54a1fb7cb7b535f4a75a2fcd9c PROTON-334: Tidied up Cyrus SASL detection in CMake - The CMake output messages now make some sense - Tidied up a few other little CMake
[GitHub] qpid-proton pull request: Mbed minor changes and sasl mech
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/19 --- 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-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=14511634#comment-14511634 ] ASF subversion and git services commented on PROTON-490: Commit 93ccc7364bfe28d3076a441409be8cbc5c88128b in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=93ccc73 ] PROTON-490: enable six.py support for operator method calls [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-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=14511633#comment-14511633 ] ASF subversion and git services commented on PROTON-490: Commit adfe2a20f0e07a6b8445b45975f15d1512599866 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=adfe2a2 ] PROTON-490: JYTHON tests cannot access site six.py so include a copy [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-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=14511636#comment-14511636 ] ASF subversion and git services commented on PROTON-490: Commit 99299d3b33e5e5ae9fbeff51ac6b7b25cacd6e85 in qpid-proton's branch refs/heads/kgiusti-python3 from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=99299d3 ] PROTON-490: get the python unit test to run in Python 3 [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] [Assigned] (PROTON-866) Implement SASL external with TLS client authentication
[ https://issues.apache.org/jira/browse/PROTON-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-866: -- Assignee: Andrew Stitcher Implement SASL external with TLS client authentication -- Key: PROTON-866 URL: https://issues.apache.org/jira/browse/PROTON-866 Project: Qpid Proton Issue Type: Sub-task Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-866) Implement SASL external with TLS client authentication
Andrew Stitcher created PROTON-866: -- Summary: Implement SASL external with TLS client authentication Key: PROTON-866 URL: https://issues.apache.org/jira/browse/PROTON-866 Project: Qpid Proton Issue Type: Sub-task Reporter: Andrew Stitcher -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PROTON-867) Enable PLAIN SASL mech iff connection is encrypted
[ https://issues.apache.org/jira/browse/PROTON-867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher reassigned PROTON-867: -- Assignee: Andrew Stitcher Enable PLAIN SASL mech iff connection is encrypted -- Key: PROTON-867 URL: https://issues.apache.org/jira/browse/PROTON-867 Project: Qpid Proton Issue Type: Sub-task Components: proton-c Reporter: Andrew Stitcher Assignee: Andrew Stitcher Currently PLAIN is never allowed because the SASL layer doesn't know when encryption is available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-867) Enable PLAIN SASL mech iff connection is encrypted
Andrew Stitcher created PROTON-867: -- Summary: Enable PLAIN SASL mech iff connection is encrypted Key: PROTON-867 URL: https://issues.apache.org/jira/browse/PROTON-867 Project: Qpid Proton Issue Type: Sub-task Reporter: Andrew Stitcher Currently PLAIN is never allowed because the SASL layer doesn't know when encryption is available -- This message was sent by Atlassian JIRA (v6.3.4#6332)
