[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532237#comment-14532237 ] ASF subversion and git services commented on PROTON-881: Commit 9daab5f836aacca3e0efde9ceff321784e4356aa in qpid-proton's branch refs/heads/proton-j-reactor from Rafael Schloming [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9daab5f ] PROTON-881: build the reactor interop test into the proton-j jar Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-877) proton-c sasl client hangs on server pipeline
[ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532238#comment-14532238 ] ASF subversion and git services commented on PROTON-877: Commit 20cdff183f7ce2c79012d5c7028eefc19a23ae28 in qpid-proton's branch refs/heads/proton-j-reactor from Rafael Schloming [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=20cdff1 ] PROTON-877: workaround by forcing anonymous from the client proton-c sasl client hangs on server pipeline - Key: PROTON-877 URL: https://issues.apache.org/jira/browse/PROTON-877 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 Attachments: pipeline-workaround.patch, tests.patch [rhs@localhost build]$ ~/proton/examples/python/reactor/send.py [0x1d350c0]: - SASL [0x1d350c0]: - SASL [0x1d350c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x1d350c0]:0 - @sasl-outcome(68) [code=0] [0x1d350c0]: - AMQP [0x1d350c0]:0 - @open(16) [container-id=, hostname=localhost] [0x1d350c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x1d350c0]:0 - @attach(18) [name=sender, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x1d350c0]: - AMQP ^CTraceback (most recent call last): File /home/rhs/proton/examples/python/reactor/send.py, line 90, in module r.run() File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 120, in run while self.process(): pass File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 142, in process result = pn_reactor_process(self._impl) KeyboardInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532239#comment-14532239 ] ASF subversion and git services commented on PROTON-881: Commit 06c451f0aadd52278770c2691ff8396d4a9587e1 in qpid-proton's branch refs/heads/proton-j-reactor from Rafael Schloming [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=06c451f ] PROTON-881: added a pom.xml for the reactor exampes Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532236#comment-14532236 ] ASF subversion and git services commented on PROTON-881: Commit 46b9d848999e993f238b37c9a0598035ccd64b27 in qpid-proton's branch refs/heads/proton-j-reactor from [~prestona] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=46b9d84 ] PROTON-881: tidy up comments and TODO's Remove TODO's if they were already done, downgrade some TODO's to comments (if they were simply observations), and remove some comments that consisted of proton-c code - pasted in as a reference. Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Reactor
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/30 --- 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-877) proton-c sasl client hangs on server pipeline
[ https://issues.apache.org/jira/browse/PROTON-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532240#comment-14532240 ] ASF GitHub Bot commented on PROTON-877: --- Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/30 proton-c sasl client hangs on server pipeline - Key: PROTON-877 URL: https://issues.apache.org/jira/browse/PROTON-877 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Rafael H. Schloming Assignee: Andrew Stitcher Fix For: 0.10 Attachments: pipeline-workaround.patch, tests.patch [rhs@localhost build]$ ~/proton/examples/python/reactor/send.py [0x1d350c0]: - SASL [0x1d350c0]: - SASL [0x1d350c0]:0 - @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]] [0x1d350c0]:0 - @sasl-outcome(68) [code=0] [0x1d350c0]: - AMQP [0x1d350c0]:0 - @open(16) [container-id=, hostname=localhost] [0x1d350c0]:0 - @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0] [0x1d350c0]:0 - @attach(18) [name=sender, handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0] [0x1d350c0]: - AMQP ^CTraceback (most recent call last): File /home/rhs/proton/examples/python/reactor/send.py, line 90, in module r.run() File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 120, in run while self.process(): pass File /home/rhs/proton/proton-c/bindings/python/proton/reactor.py, line 142, in process result = pn_reactor_process(self._impl) KeyboardInterrupt -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: codec changes
On Wed, 2015-05-06 at 14:03 -0400, Rafael Schloming wrote: We seem to have reached consensus here, but I haven't seen any commits on this. We should probably fix this before 0.10 so we don't end up putting out a new API and then deprecating it in the next release. Is anyone actually working on this? Could you articulate the consensus then. Asserting we have reached consensus without explicitly stating what you think the consensus to be is remarkably likely to be proven wrong by subsequent events! Andrew
Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]
On Thu, May 7, 2015 at 2:52 PM, Alan Conway acon...@redhat.com wrote: - Original Message - The recent landing of the Go changes make me think that we should be more explicit about our development process with respect to new language bindings (or possibly in general). There are two problems I would like to address. First, a bunch of code just landed on trunk without prior communication/peer review right as we are trying to stabilize for 0.10. With the go binding work having started/proceeded directly on trunk, I can't tell if this is a rush commit to get stuff into 0.10, or if it's just more ongoing development that was assumed to not impact the stated 0.10 goals. Secondly, from a release management perspective it is in general awkward to have early stage development mixed in with changes to a stable codebase. The git history between 0.9, 0.9.1, and master is currently a mix of high fidelity changes, e.g. discrete bug fixes/feature enhancements all cluttered up with a bunch of more noisy checkpoint/work-in-progress style commits for the go binding that are a normal part of early stage development work. This makes things hard when it comes to release management as there is a lot of noise to sort through when running git cherry and the like. I'd like to propose getting a bit more formal about the following policy, especially now that we are fully using git and branches are cheap. I think a number of people already follow this implicitly, but as a whole we are somewhat inconsistent about it (myself included at times): 1. For developing new language bindings (and really for any development work that will involve enough new stuff to have a noisy commit history) we use branches. This is already the case with the Ruby/C++/Python3 bindings, as well as the SASL work. 2. We should discuss on the mailing list before we land major features. We were trying to stabilize trunk for a 0.10 release, and this hasn't been in the discussion, and a number of things have been broken in the recent commits. :)) I didn't follow the process 'cause there wasn't one :) This process makes perfect sense, I will move the go work to a go branch to comply. n fairness to me I did ask on the list whether I should do this on a branch or whether it was OK on trunk blah, blah, whine, whine, poor me etc. In fairness to the new process I did break the build with a go commit. Not because of the go binding but because of an emacs keyboard twitch leaving random characters in a python file I was viewing. Being on a branch would have saved me that embarrassment. I think I pretty much said go ahead on master, so apologies for singling you out. It's awesome that lots of new binding work is happening and I think it's just a natural part of any project's growing pains to introduce a bit more process when dealing with a code base that has both stable/mature parts and newly expanding parts. --Rafael
Re: codec changes
I believe where we ended up was standardizing on a single snprintf-style signature for all encode functions, i.e.: // always returns encoded size, never overwrites limit, pass in NULL, 0 to compute size in advance // returns 0 if there was an actual error of some sort, e.g. xxx_t cannot be validly encoded for some reason ssize_t pn_xxx_encode(xxx_t, char *buf, size_t limit); And transitioning to this with a feature macro. --Rafael On Thu, May 7, 2015 at 3:28 PM, Andrew Stitcher astitc...@redhat.com wrote: On Wed, 2015-05-06 at 14:03 -0400, Rafael Schloming wrote: We seem to have reached consensus here, but I haven't seen any commits on this. We should probably fix this before 0.10 so we don't end up putting out a new API and then deprecating it in the next release. Is anyone actually working on this? Could you articulate the consensus then. Asserting we have reached consensus without explicitly stating what you think the consensus to be is remarkably likely to be proven wrong by subsequent events! Andrew
Re: Development workflow and release process [WAS: Concurrent Go API for proton is, erm, GO!]
- Original Message - The recent landing of the Go changes make me think that we should be more explicit about our development process with respect to new language bindings (or possibly in general). There are two problems I would like to address. First, a bunch of code just landed on trunk without prior communication/peer review right as we are trying to stabilize for 0.10. With the go binding work having started/proceeded directly on trunk, I can't tell if this is a rush commit to get stuff into 0.10, or if it's just more ongoing development that was assumed to not impact the stated 0.10 goals. Secondly, from a release management perspective it is in general awkward to have early stage development mixed in with changes to a stable codebase. The git history between 0.9, 0.9.1, and master is currently a mix of high fidelity changes, e.g. discrete bug fixes/feature enhancements all cluttered up with a bunch of more noisy checkpoint/work-in-progress style commits for the go binding that are a normal part of early stage development work. This makes things hard when it comes to release management as there is a lot of noise to sort through when running git cherry and the like. I'd like to propose getting a bit more formal about the following policy, especially now that we are fully using git and branches are cheap. I think a number of people already follow this implicitly, but as a whole we are somewhat inconsistent about it (myself included at times): 1. For developing new language bindings (and really for any development work that will involve enough new stuff to have a noisy commit history) we use branches. This is already the case with the Ruby/C++/Python3 bindings, as well as the SASL work. 2. We should discuss on the mailing list before we land major features. We were trying to stabilize trunk for a 0.10 release, and this hasn't been in the discussion, and a number of things have been broken in the recent commits. :)) I didn't follow the process 'cause there wasn't one :) This process makes perfect sense, I will move the go work to a go branch to comply. n fairness to me I did ask on the list whether I should do this on a branch or whether it was OK on trunk blah, blah, whine, whine, poor me etc. In fairness to the new process I did break the build with a go commit. Not because of the go binding but because of an emacs keyboard twitch leaving random characters in a python file I was viewing. Being on a branch would have saved me that embarrassment. Cheers, Alan.
Re: javascript appears to be broken again
On Thu, 2015-05-07 at 11:09 -0400, Andrew Stitcher wrote: On Wed, 2015-05-06 at 23:42 +0100, Gordon Sim wrote: ... Apparently these are posix functions and are not included in c99. Using the proton equivalents in util.h works. Let me know if you want me to commit that. Gah, sorry I should have spotted that myself earlier. I will fix it - I think the current solution we have for strncasecmp isn't great and I'll fix that at the same time. Should be fixed on master as of beaea0c1cc8237. Sorry, about that - I wonder if there's a way to stop non C99 symbols being visible, so that I won't keep on using strdup etc. thoughtlessly. Anyone have an idea? Would turning strict C99 mode on stop gcc from allowing POSIX only symbols? Andrew
Draft board report for May
Hi folks, Our quarterly report to the board is due by Wed 13th. I have written an initial draft which you can find below. Let me know if you have any additions/changes before I submit it on Monday. Robbie === Apache Qpid is a project focused on creating software based on the Advanced Message Queuing Protocol (AMQP), currently providing a protocol engine library, message brokers written in C++ and Java, a message router, and client libraries for C++, Java / JMS, .Net, Python, Perl and Ruby. # Releases: - Qpid 0.32 was released on 19th March 2015. - Qpid JMS client 0.1.0 was released on 19th March 2015. - Qpid Proton 0.9 was released on 31st March 2015. - Qpid Dispatch router 0.4 was released on 9th April 2015. - Qpid Proton 0.9.1 was released on 2nd May 2015. # Community: - The main developer and user lists continue to be active. -- d...@qpid.apache.org: 184 subscribers (no change), 1992 emails (1287 previous). -- us...@qpid.apache.org: 360 subscribers (down 1), 557 emails (338 previous). -- proton@qpid.apache.org: 88 subscribers (up 6), 1004 emails (580 previous). - JIRAs are being raised and addressed. 277 JIRA tickets were created and 296 resolved in the last 3 months. - There were no new committers added since the last report. The last new committer was Dominic Evans on 12th Dec 2014. - There were 7 new PMC members added since the last report: Alex Rudyy was added on 3rd March 2015 Dominic Evans was added on 3rd March 2015 Ken Giusti was added on 3rd March 2015 Timothy Bish was added on 3rd March 2015 Pavel Moravec was added on 4th March 2015 Cliff Jansen was added on 6th March 2015 Darryl Pierce was added on 6th March 2015 # Development: - The new AMQP 1.0 JMS client had its first release as mentioned earlier. We have been working on improvements and fixes since then and will be looking to do a 0.2.0 release imminently. - Discussions and work to begin preparing for a Qpid Proton 0.10 have begun, incorporating some major SASL related changes since 0.9. Work also continues on expanding language support for the new Reactor API's to Go, C++, Ruby, and Java, some of which may be aimed at the following release. - Following the Qpid 0.32 release there was intent to reorganise the repository structure to better support releasing the various components on their own schedules going forward, as has been the case for newer components. The Java broker, earlier clients and associated items have been relocated to a new trunk, with further relocations still to come for other components. # Issues: There are no Board-level issues at this time.
[GitHub] qpid-proton pull request: Reactor
Github user gemmellr commented on a diff in the pull request: https://github.com/apache/qpid-proton/pull/29#discussion_r29843571 --- Diff: proton-j/src/main/java/org/apache/qpid/proton/engine/impl/EventImpl.java --- @@ -157,12 +165,51 @@ public void dispatch(Handler handler) case TRANSPORT_CLOSED: handler.onTransportClosed(this); break; +case REACTOR_FINAL: +handler.onReactorFinal(this); +break; +case REACTOR_QUIESCED: +handler.onReactorQuiesced(this); +break; +case REACTOR_INIT: +handler.onReactorInit(this); +break; +case SELECTABLE_ERROR: +handler.onSelectableError(this); +break; +case SELECTABLE_EXPIRED: +handler.onSelectableExpired(this); +break; +case SELECTABLE_FINAL: +handler.onSelectableFinal(this); +break; +case SELECTABLE_INIT: +handler.onSelectableInit(this); +break; +case SELECTABLE_READABLE: +handler.onSelectableReadable(this); +break; +case SELECTABLE_UPDATED: +handler.onSelectableWritable(this); +break; +case SELECTABLE_WRITABLE: +handler.onSelectableWritable(this); +break; +case TIMER_TASK: +handler.onTimerTask(this); +break; default: handler.onUnhandled(this); break; } + +IteratorHandler children = handler.children(); --- End diff -- Commenting here to avoid spamming the semi-unrelated JIRA mentioned linked with the other PR that got merged. I have only skimmed this PR, since I haven't got much of experience of the reactor code in any of the other languages, so I'm not sure what many things are actually meant to do. It felt a little strange at times that some of the Connection etc objects now have some very reactor specific methods even though you might not be using the reactor with them (i.e all existing use), but I can certainly live with that if thats how it works elsewhere, and they presumably dont hurt anything if you dont use them. I did spot this 1 specific bit though, where I think it would be nice to optimise for what anyone using this currently will be doing. Existing handlers wont have any children, and that would currently mean that every time you dispatch an event you will create a pointless iterator, so it would be nice to avoid that in the case of no children. --- 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: Reactor
On Thu, May 7, 2015 at 7:29 AM, gemmellr g...@git.apache.org wrote: Github user gemmellr commented on a diff in the pull request: https://github.com/apache/qpid-proton/pull/29#discussion_r29843571 --- Diff: proton-j/src/main/java/org/apache/qpid/proton/engine/impl/EventImpl.java --- @@ -157,12 +165,51 @@ public void dispatch(Handler handler) case TRANSPORT_CLOSED: handler.onTransportClosed(this); break; +case REACTOR_FINAL: +handler.onReactorFinal(this); +break; +case REACTOR_QUIESCED: +handler.onReactorQuiesced(this); +break; +case REACTOR_INIT: +handler.onReactorInit(this); +break; +case SELECTABLE_ERROR: +handler.onSelectableError(this); +break; +case SELECTABLE_EXPIRED: +handler.onSelectableExpired(this); +break; +case SELECTABLE_FINAL: +handler.onSelectableFinal(this); +break; +case SELECTABLE_INIT: +handler.onSelectableInit(this); +break; +case SELECTABLE_READABLE: +handler.onSelectableReadable(this); +break; +case SELECTABLE_UPDATED: +handler.onSelectableWritable(this); +break; +case SELECTABLE_WRITABLE: +handler.onSelectableWritable(this); +break; +case TIMER_TASK: +handler.onTimerTask(this); +break; default: handler.onUnhandled(this); break; } + +IteratorHandler children = handler.children(); --- End diff -- Commenting here to avoid spamming the semi-unrelated JIRA mentioned linked with the other PR that got merged. I have only skimmed this PR, since I haven't got much of experience of the reactor code in any of the other languages, so I'm not sure what many things are actually meant to do. It felt a little strange at times that some of the Connection etc objects now have some very reactor specific methods even though you might not be using the reactor with them (i.e all existing use), but I can certainly live with that if thats how it works elsewhere, and they presumably dont hurt anything if you dont use them. There may be a way to reduce the coupling a little bit there (I'm currently looking into that), but in the end it simply becomes awkward to write event handlers without being able to navigate from all the various engine objects back to the reactor that holds them. I did spot this 1 specific bit though, where I think it would be nice to optimise for what anyone using this currently will be doing. Existing handlers wont have any children, and that would currently mean that every time you dispatch an event you will create a pointless iterator, so it would be nice to avoid that in the case of no children. Agreed. I need to tweak event dispatch to support some other scenarios, so I'll probably be messing with that code anyways. I'll make sure it doesn't create extraneous objects when I do. --Rafael
Introducing the Ruby Reactive APIs
I've been working on this codebase since the beginning of the year. The two branches [1, 2] in my git repo represent the low-level engine APIs and the higher-level reactive APIs, respectively. I'm still working through the set of example apps for the reactive APIs, but at this point I feel this is close enough that I want to start getting feedback from people. == Memory Concerns Of particular important is memory management: the Proton libraries use reference counting to manage object lifespans, while Ruby uses mark and sweep operations for garbage collection. So ensuring that pure Ruby objects aren't reaped when they've only known to the Proton libraries, in the case of event handlers specifically, has been a challenge and one that's sure to have some cases that need fixing. The first model explored was to attachment the Ruby wrapper objects to the Swig-generated wrappers for the underlying C structs in Proton. Which worked at first, but turned out to be not useful. The reason being that the Swig bindings were themselves being reaped when they went out of scope; i.e., Swig doesn't maintain them by providing a mark operation until disposal of the underlying C structs. So this path, while initially promising, was discarded. The current model uses a hash table that is attached to the Qpid::Proton module. When objects are stored for use by the C libraries, they are tucked away in this hash table with a unique key generated based on memory addresses. A copy of that key, as a char*, is given to Proton to use later when the object is being retrieved. To help with this, two additional callback APIs were added to the Proton libraries: pn_record_set_callback and pn_record_has_callback. These two functions work to help register a method to be called whenever a record is deleted to enable memory management. This way the above-mentioned key can be properly deleted, and the value stored in the hash table discarded. The reference counting aspect of the Proton libraries is a concern as well. The code currently increments and decrements references in the same places as the Python code, but there are likely more places where such reference accounting need to be added. [1] http://github.com/mcpierce/Proton/tree/PROTON-799-Ruby-engine-apis [2] http://github.com/mcpierce/Proton/tree/PROTON-781-reactive-ruby-apis -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpXevt2WqzQw.pgp Description: PGP signature
Re: Introducing the Ruby Reactive APIs
On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce dpie...@redhat.com wrote: I've been working on this codebase since the beginning of the year. The two branches [1, 2] in my git repo represent the low-level engine APIs and the higher-level reactive APIs, respectively. I'm still working through the set of example apps for the reactive APIs, but at this point I feel this is close enough that I want to start getting feedback from people. == Memory Concerns Of particular important is memory management: the Proton libraries use reference counting to manage object lifespans, while Ruby uses mark and sweep operations for garbage collection. So ensuring that pure Ruby objects aren't reaped when they've only known to the Proton libraries, in the case of event handlers specifically, has been a challenge and one that's sure to have some cases that need fixing. The first model explored was to attachment the Ruby wrapper objects to the Swig-generated wrappers for the underlying C structs in Proton. Which worked at first, but turned out to be not useful. The reason being that the Swig bindings were themselves being reaped when they went out of scope; i.e., Swig doesn't maintain them by providing a mark operation until disposal of the underlying C structs. So this path, while initially promising, was discarded. The current model uses a hash table that is attached to the Qpid::Proton module. When objects are stored for use by the C libraries, they are tucked away in this hash table with a unique key generated based on memory addresses. A copy of that key, as a char*, is given to Proton to use later when the object is being retrieved. To help with this, two additional callback APIs were added to the Proton libraries: pn_record_set_callback and pn_record_has_callback. These two functions work to help register a method to be called whenever a record is deleted to enable memory management. This way the above-mentioned key can be properly deleted, and the value stored in the hash table discarded. I would need to see the code in detail, but I suspect you don't need to add a pn_record_set_callback/get_callback to achieve roughly the functionality. I *think* you could simply define a pn_class_t that is a reference counted holder of your key. You could then put your callback logic in the finalizer for that class, and when proton's reference counting triggers the finalizer, it will run the callback logic at the appropriate time. The reference counting aspect of the Proton libraries is a concern as well. The code currently increments and decrements references in the same places as the Python code, but there are likely more places where such reference accounting need to be added. [1] http://github.com/mcpierce/Proton/tree/PROTON-799-Ruby-engine-apis [2] http://github.com/mcpierce/Proton/tree/PROTON-781-reactive-ruby-apis -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
[jira] [Commented] (PROTON-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532690#comment-14532690 ] ASF subversion and git services commented on PROTON-865: Commit 26d74105f3bef4e4384b4bdd9ee4c179ba9027b1 in qpid-proton's branch refs/heads/cjansen-cpp-client from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=26d7410 ] PROTON-865: Message properties, Acking and Delivery 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)
Re: Introducing the Ruby Reactive APIs
On Thu, May 07, 2015 at 11:32:33AM -0400, Rafael Schloming wrote: On Thu, May 7, 2015 at 10:40 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, May 07, 2015 at 09:57:49AM -0400, Rafael Schloming wrote: On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce dpie...@redhat.com wrote: snip To help with this, two additional callback APIs were added to the Proton libraries: pn_record_set_callback and pn_record_has_callback. These two functions work to help register a method to be called whenever a record is deleted to enable memory management. This way the above-mentioned key can be properly deleted, and the value stored in the hash table discarded. I would need to see the code in detail, but I suspect you don't need to add a pn_record_set_callback/get_callback to achieve roughly the functionality. I *think* you could simply define a pn_class_t that is a reference counted holder of your key. You could then put your callback logic in the finalizer for that class, and when proton's reference counting triggers the finalizer, it will run the callback logic at the appropriate time. (edit) As I was writing up a description of the code I realized I have already done what you suggest above WRT the pni_rbhandler_t type. I could use the same logic to create a pni_rbrecord_t type and manage its lifecycle the same way the handler's lifecycles are managed, yeah? Yes, I believe so. Since records are created when a struct if initially created, I'm not sure how to go about attaching the key to its lifecycle since the dynamic language isn't explicitly creating the record. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpPrDtwTjlAX.pgp Description: PGP signature
Re: javascript appears to be broken again
On Wed, 2015-05-06 at 23:42 +0100, Gordon Sim wrote: ... Apparently these are posix functions and are not included in c99. Using the proton equivalents in util.h works. Let me know if you want me to commit that. Gah, sorry I should have spotted that myself earlier. I will fix it - I think the current solution we have for strncasecmp isn't great and I'll fix that at the same time. Andrew
Re: Introducing the Ruby Reactive APIs
On Thu, May 07, 2015 at 09:57:49AM -0400, Rafael Schloming wrote: On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce dpie...@redhat.com wrote: snip To help with this, two additional callback APIs were added to the Proton libraries: pn_record_set_callback and pn_record_has_callback. These two functions work to help register a method to be called whenever a record is deleted to enable memory management. This way the above-mentioned key can be properly deleted, and the value stored in the hash table discarded. I would need to see the code in detail, but I suspect you don't need to add a pn_record_set_callback/get_callback to achieve roughly the functionality. I *think* you could simply define a pn_class_t that is a reference counted holder of your key. You could then put your callback logic in the finalizer for that class, and when proton's reference counting triggers the finalizer, it will run the callback logic at the appropriate time. (edit) As I was writing up a description of the code I realized I have already done what you suggest above WRT the pni_rbhandler_t type. I could use the same logic to create a pni_rbrecord_t type and manage its lifecycle the same way the handler's lifecycles are managed, yeah? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpFxlAV42Im8.pgp Description: PGP signature
[jira] [Commented] (PROTON-881) Proton-j reactor implementation
[ https://issues.apache.org/jira/browse/PROTON-881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532849#comment-14532849 ] ASF subversion and git services commented on PROTON-881: Commit f87038b5ad62aef6867855f98fee08cca974 in qpid-proton's branch refs/heads/proton-j-reactor from Rafael Schloming [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=f870333 ] PROTON-881: added Record attachments in favor of modifying endpoints to know about handlers Proton-j reactor implementation --- Key: PROTON-881 URL: https://issues.apache.org/jira/browse/PROTON-881 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.9 Reporter: Adrian Preston Priority: Minor To keep the proton-j codebase consistent with proton-c - there should be a native Java port of the reactor. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-697) SChannel SSL/TLS support for Proton-c on Windows
[ https://issues.apache.org/jira/browse/PROTON-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14532960#comment-14532960 ] ASF GitHub Bot commented on PROTON-697: --- Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/2#issuecomment-99931684 The JIRA is marked complete, but none of the commits included the message to auto close the PR. Can you close it @cliffjansen? SChannel SSL/TLS support for Proton-c on Windows Key: PROTON-697 URL: https://issues.apache.org/jira/browse/PROTON-697 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.8 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.9 This JIRA tracks the progress of completing SChannel functionality in Proton beyond the start in PROTON-581. The target is Proton 0.9. This includes support for incoming connections client side certificates Windows registry and file based certificate stores Control over certificate name checking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-697: part 1, server support and d...
Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/2#issuecomment-99931684 The JIRA is marked complete, but none of the commits included the message to auto close the PR. Can you close it @cliffjansen? --- 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: Introducing the Ruby Reactive APIs
On Thu, May 7, 2015 at 11:49 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, May 07, 2015 at 11:32:33AM -0400, Rafael Schloming wrote: On Thu, May 7, 2015 at 10:40 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, May 07, 2015 at 09:57:49AM -0400, Rafael Schloming wrote: On Thu, May 7, 2015 at 9:41 AM, Darryl L. Pierce dpie...@redhat.com wrote: snip To help with this, two additional callback APIs were added to the Proton libraries: pn_record_set_callback and pn_record_has_callback. These two functions work to help register a method to be called whenever a record is deleted to enable memory management. This way the above-mentioned key can be properly deleted, and the value stored in the hash table discarded. I would need to see the code in detail, but I suspect you don't need to add a pn_record_set_callback/get_callback to achieve roughly the functionality. I *think* you could simply define a pn_class_t that is a reference counted holder of your key. You could then put your callback logic in the finalizer for that class, and when proton's reference counting triggers the finalizer, it will run the callback logic at the appropriate time. (edit) As I was writing up a description of the code I realized I have already done what you suggest above WRT the pni_rbhandler_t type. I could use the same logic to create a pni_rbrecord_t type and manage its lifecycle the same way the handler's lifecycles are managed, yeah? Yes, I believe so. Since records are created when a struct if initially created, I'm not sure how to go about attaching the key to its lifecycle since the dynamic language isn't explicitly creating the record. The way the python code does this is by checking whenever a C object is returned to python code. If the record contains an attachment indicating that the C object has previously been wrapped, it uses this to construct/retrieve an appropriate wrapper object. If it doesn't have the appropriate attachment then it uses the record API to define/set the attachment to the appropriate value. I presume you could do something similar with ruby. --Rafael
[jira] [Closed] (PROTON-697) SChannel SSL/TLS support for Proton-c on Windows
[ https://issues.apache.org/jira/browse/PROTON-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-697. --- SChannel SSL/TLS support for Proton-c on Windows Key: PROTON-697 URL: https://issues.apache.org/jira/browse/PROTON-697 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.8 Environment: Windows Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: 0.9 This JIRA tracks the progress of completing SChannel functionality in Proton beyond the start in PROTON-581. The target is Proton 0.9. This includes support for incoming connections client side certificates Windows registry and file based certificate stores Control over certificate name checking -- This message was sent by Atlassian JIRA (v6.3.4#6332)
