[GitHub] qpid-proton pull request: Initial transport frame size 256 bytes
Github user dnwe commented on the pull request: https://github.com/apache/qpid-proton/pull/25#issuecomment-100819482 @dcristoloveanu you don't appear to have pushed the updated commits for this PR - could you also `git pull --rebase` from master and then squash into a single commit with the updates --- 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-727) Add a NULL-pointer checks to malloc() and realloc() calls
[
https://issues.apache.org/jira/browse/PROTON-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14537725#comment-14537725
]
ASF GitHub Bot commented on PROTON-727:
---
Github user asfgit closed the pull request at:
https://github.com/apache/qpid-proton/pull/27
Add a NULL-pointer checks to malloc() and realloc() calls
-
Key: PROTON-727
URL: https://issues.apache.org/jira/browse/PROTON-727
Project: Qpid Proton
Issue Type: Wish
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd (PrE)
Priority: Minor
As we are running the ProtonC project on memory constrained systems, it is
possible for malloc() or realloc() to return a NULL, when there is no more
free heap to allocate the memory from.
Obviously, we might have a specific optimizations in the ProtonC code, which
deeply minimize the amount of a total heap required, but this is not what
this ticket is referring to.
In any case where there is no more free heap, or in a case where there is any
other issue with the allocators, the memory allocation functions return NULL.
The ProtonC code at this state, does not check for such a situation, and it
always expects the malloc() and realloc() to work and to return a valid
pointer.
I would like the developers to add a specific test to each place, where
memory allocation takes place, and to act upon an error properly (ideally -
with a graceful closure of the connection to broker, if possible).
Also, a proper signalization path to the user's application (which runs the
ProtonC client) would be a great addition.
If nothing fancy is planned, I would, at least, ask for adding the simple {{
if (x == NULL) { do something }; }} tests to each every place where memory
allocation is handled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] qpid-proton pull request: Add some NULL checks and fix some reallo...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/27 --- 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-883) Return the raw bytes as an array for a message in Ruby
Darryl L. Pierce created PROTON-883: --- Summary: Return the raw bytes as an array for a message in Ruby Key: PROTON-883 URL: https://issues.apache.org/jira/browse/PROTON-883 Project: Qpid Proton Issue Type: Improvement Components: ruby-binding Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce When retrieving a message that contains raw bytes rather than strings, the Swig bindings can return a truncated string. This is due to the method SWIG_FromCharPtr stopping at the first 0 byte since it's treating the content as a C string and not as an array of bytes. The code should, instead, using something like SWIG_FromCharPtrAndSize to return the full content and not guess at the length based on null bytes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
When pushing to the git repo, please avoid merge commits...
A request for all, please avoid doing merge commits on your Git repo. When these hit the shared repo it can cause Git to try and fix [1] the commit when rebasing. The way I do commits with Git is to rebase my work branch on master before merging it into master. That way it's a true merge and not a merge commit. To do this: 1. Rebase your work branch: task-branch $ git rebase -i master 2. Fix any merge issues on the work branch until you get a clean set of commits. 3. Switch to master and then merge your branch: task-branch $ git checkout master master-branch $ git merge task-branch Thanks. [1] On my task branches I use autofix to merge changes back to the appropriate previous commit in my branch. When I'm ready to merge them I use git rebase -i HEAD~[some # of commits] --autofix. Git then takes all of the autofix commits and puts them after the appropriate commit to merge together. If I a merge commit is accidentally included in there then git will try to rebase that merge commit and all hell can break loose. -- 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/ pgpfWWtjMVeGY.pgp Description: PGP signature
[jira] [Created] (PROTON-884) [C Windows] python transport tracer breaks windows build
Chuck Rolke created PROTON-884:
--
Summary: [C Windows] python transport tracer breaks windows build
Key: PROTON-884
URL: https://issues.apache.org/jira/browse/PROTON-884
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Environment: Win Server 2008, Visual Studio 2008 x86
Reporter: Chuck Rolke
{noformat}
12.\cprotonPYTHON_wrap.cxx(3611) : error C2440: 'initializing' : cannot
convert from 'void *' to 'PyObject *'
12Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: When pushing to the git repo, please avoid merge commits...
On Mon, May 11, 2015 at 09:23:27AM -0400, Darryl L. Pierce wrote: A request for all, please avoid doing merge commits on your Git repo. When these hit the shared repo it can cause Git to try and fix [1] the commit when rebasing. The way I do commits with Git is to rebase my work branch on master before merging it into master. That way it's a true merge and not a merge commit. To do this: 1. Rebase your work branch: task-branch $ git rebase -i master 2. Fix any merge issues on the work branch until you get a clean set of commits. 3. Switch to master and then merge your branch: task-branch $ git checkout master master-branch $ git merge task-branch Thanks. [1] On my task branches I use autofix to merge changes back to the appropriate previous commit in my branch. When I'm ready to merge them I use git rebase -i HEAD~[some # of commits] --autofix. Git then takes all of the autofix commits and puts them after the appropriate commit to merge together. If I a merge commit is accidentally included in there then git will try to rebase that merge commit and all hell can break loose. Dug out this old post to my blog that has my steps for doing the commits on a task-based branch: http://mcpierce.blogspot.com/2012/08/git-fixup-and-autosquash.html I've added a new comment on this post with the steps for doing an autofix commit, but will write up a newer version of the post to include this inline. -- 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/ pgp_NkrC53d2E.pgp Description: PGP signature
[jira] [Commented] (PROTON-884) [C Windows] python transport tracer breaks windows build
[
https://issues.apache.org/jira/browse/PROTON-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14537940#comment-14537940
]
ASF subversion and git services commented on PROTON-884:
Commit c8f2d8a3aea0ffedc4b498e8146bfc0baa1562c3 in qpid-proton's branch
refs/heads/master from [~chug]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c8f2d8a ]
PROTON-884: add explicit cast for win build
[C Windows] python transport tracer breaks windows build
Key: PROTON-884
URL: https://issues.apache.org/jira/browse/PROTON-884
Project: Qpid Proton
Issue Type: Bug
Components: proton-c, python-binding
Affects Versions: 0.10
Environment: Win Server 2008, Visual Studio 2008 x86
Reporter: Chuck Rolke
{noformat}
12.\cprotonPYTHON_wrap.cxx(3611) : error C2440: 'initializing' : cannot
convert from 'void *' to 'PyObject *'
12Conversion from 'void*' to pointer to non-'void' requires an
explicit cast
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Draft board report for May
On 7 May 2015 at 11:58, Robbie Gemmell robbie.gemm...@gmail.com wrote: Well, sent to the wrong p*@q.a.o mailing list, oops. No harm, there isnt anything in it to be kept private. As it isnt proton specific, adding dev@ as well. Robbie On 7 May 2015 at 11:42, Robbie Gemmell robbie.gemm...@gmail.com wrote: 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. I have now submitted the report, as above. Robbie
[GitHub] qpid-proton pull request: Initial transport frame size 256 bytes
Github user dcristoloveanu commented on the pull request: https://github.com/apache/qpid-proton/pull/25#issuecomment-100987919 @dnwe Sorry about that, I updated the branch to have only on commit. 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. ---
Heads Up: Proton master can't be built with ccache swig
Since Rafi pushed 223bbc8bd50a34282ef02952392fd4321113f770 my Linux (Fedora 21) builds have been failing [1]. I've finally tracked it down to some problem with ccache-swig. So if you have ccache installed (which is generally a good idea as it speeds up builds a lot) you need to avoid the ccache version of swig. If cmake is using the version of swig which doesn't work you will see that the swig found is in /usr/lib64/ccache/swig Do this either by using ccmake (or cmake-gui) to change SWIG_EXECUTABLE to /usr/bin/swig or by using -DSWIG_EXECUTABLE=/usr/bin/swig on the initial cmake line. I don't know if this information is also true for Debian/Ubuntu with ccache. Andrew [1] The errors look like this: [2/4] Swig source linking /home/andrew/Work/proton/bld/proton-c/bindings/python/cprotonPYTHON_wrap.c (cc) /home/andrew/Work/proton/src/proton-c/bindings/python/cproton.i:297: Error: Syntax error in input(1). ninja: build stopped: cannot make progress due to previous errors.
Re: Introducing the Ruby Reactive APIs
On Thu, May 07, 2015 at 01:02:13PM -0400, Rafael Schloming wrote: 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. After we chatted the other day, I've tried the following approach, using the pn_transport_t type as my test bed since it has relatively fewer dependencies. However, the plumbing in Proton for objects isn't quite clear to me and my code's not quite working the way we had discussed and I'm not sure why. The goal is to have a type that will live for as long as one of the impls in Proton lives; i.e., when we create something like pn_transport_t, the attachment created for this would hold some type that will get finalized when the pn_transport_t type is finalized. And that type would be the hook to clean up the single instance of a Ruby class that wraps the underlying C type. I've created a new type in the ruby.i descriptor for Swig and named it pn_rbkey_t, with three files: void* registry (a pointer to an object held in Ruby), char* method (the name of a method to invoke on that object), and char* key_value (the argument to be passed to that method). The code defines pn_rbkey_initialize and pn_rbkey_finalize methods, as well as getter and setter methods for the three fields. But I've put debugging into the code and never see the pn_rbkey_finalize method being invoked. My registry_test app does the following: 1. create an instance of pn_transport_t: impl = Cproton.pn_transport 2. create a Ruby Transport object: transport = Transport.wrap(impl) a. puts a weak reference to the Transport into the hashtable b. creates a pn_rbkey_t object and sets it as the sole record for the pn_transport_t object c. calls Cproton.pn_incref on the pn_rbkey_t instance 3. remove the reference: transport = nil 4. call garbage collection: ObjectSpace.garbage_collect 5. get the object back: transport = Transport.wrap(impl) a. calls pn_transport_attachment and retrieves the record created in 2 b. should then be able to get the key_value from the pn_rbkey_t type c. should then get the object out of the hashtable to return It's at step 5 that the example app segfaults. The segfault happens when, from Ruby, there's a call to print the attachment retrieve in 5a. Swig isn't failing since it's returning a value that seems to have been cached. But when Swig tries to retrieve data from the pn_rbkey_t struct underneath of it, *THAT* seems to have been reaped by Proton and Swig then segfaults, thinking there was an object still under the covers. Any ideas or suggestions of where to look for what's going on? -- 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/ pgpmyZ1IC9zbA.pgp Description: PGP signature
[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=14538547#comment-14538547 ] ASF subversion and git services commented on PROTON-877: Commit 520f0d8e3d215dbd38b8ae0d9222f5a66d860c66 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=520f0d8 ] PROTON-877: Move client outcome processing to output side - Also add some (somewhat imperfect) tests 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] [Resolved] (PROTON-562) More gracefully handle connections to non-1.0 parties
[
https://issues.apache.org/jira/browse/PROTON-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-562.
Resolution: Fixed
The misleading error messages are no longer present, and the underlying code
has a very good idea about what problem there might be, however dues to
PROTON-574 there is no useful error information propagated to the user.
More gracefully handle connections to non-1.0 parties
-
Key: PROTON-562
URL: https://issues.apache.org/jira/browse/PROTON-562
Project: Qpid Proton
Issue Type: Improvement
Affects Versions: 0.7
Reporter: Justin Ross
Assignee: Andrew Stitcher
Priority: Minor
Right now, attempting a connection from messenger to a 0-10 only qpidd
results in a SASL header mismatch. That's correct but less helpful than it
might be.
{noformat}
jross@localhost bailey$ LD_LIBRARY_PATH=/tmp/tmp.mXaVrrHF8a/lib64
PYTHONPATH=/tmp/tmp.mXaVrrHF8a/lib64/proton/bindings/python/ PN_TRACE_FRM=1
python ~/test.py
[0x2418e30]: - SASL
[0x2418e30]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b]
[0x2418e30]:ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
[0x2418e30]: - EOS
[0x2418e30]:ERROR[-2] SASL header mismatch: ''
[0x2418e30]: - EOS
CONNECTION ERROR connection aborted (remote)
{noformat}
See
https://issues.apache.org/jira/browse/PROTON-561?focusedCommentId=13966905page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13966905
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PROTON-562) More gracefully handle connections to non-1.0 parties
[
https://issues.apache.org/jira/browse/PROTON-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-562:
---
Fix Version/s: (was: 0.10)
0.9
More gracefully handle connections to non-1.0 parties
-
Key: PROTON-562
URL: https://issues.apache.org/jira/browse/PROTON-562
Project: Qpid Proton
Issue Type: Improvement
Affects Versions: 0.7
Reporter: Justin Ross
Assignee: Andrew Stitcher
Priority: Minor
Fix For: 0.9
Right now, attempting a connection from messenger to a 0-10 only qpidd
results in a SASL header mismatch. That's correct but less helpful than it
might be.
{noformat}
jross@localhost bailey$ LD_LIBRARY_PATH=/tmp/tmp.mXaVrrHF8a/lib64
PYTHONPATH=/tmp/tmp.mXaVrrHF8a/lib64/proton/bindings/python/ PN_TRACE_FRM=1
python ~/test.py
[0x2418e30]: - SASL
[0x2418e30]:0 - @sasl-init(65) [mechanism=:ANONYMOUS, initial-response=b]
[0x2418e30]:ERROR[-2] SASL header mismatch: 'AMQP\x01\x01\x00\x0a'
[0x2418e30]: - EOS
[0x2418e30]:ERROR[-2] SASL header mismatch: ''
[0x2418e30]: - EOS
CONNECTION ERROR connection aborted (remote)
{noformat}
See
https://issues.apache.org/jira/browse/PROTON-561?focusedCommentId=13966905page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13966905
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: codec changes
On Thu, 2015-05-07 at 15:53 -0400, Rafael Schloming wrote: 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. I'm good with sprintf-style. I'm not sure what you mean by a feature macro. Does that addresses binary compatibility or is just a source-level switch? If we break binary compatibility we need to make sure we bump the library version appropriately to avoid breaking existing apps. If we set the switch to default to the new behavior we should make sure the compiler barfs on old code and it's fairly obvious what to do about it. Cheers, Alan. --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
[jira] [Resolved] (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:all-tabpanel ] Andrew Stitcher resolved PROTON-877. Resolution: Fixed 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-865) C++ reactor client binding
[ https://issues.apache.org/jira/browse/PROTON-865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14539111#comment-14539111 ] ASF subversion and git services commented on PROTON-865: Commit e0db6ea98ab3f63ecdeb5a0e6f5885128b5e2d1a 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=e0db6ea ] PROTON-865: Added basic Terminus, Broker.cpp example 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)
