QQ

On Mon, 2015-12-14 at 11:40 -0700, Philippe Le Rohellec wrote: > Thanks Alan, > > I tried that but a recent change to the SWIG bindings broke the > reactor > interface in ruby. I commented on > https://issues.apache.org/jira/browse/PROTON-949 as you already notic > ed. > Even after it's fixed

Re: [VOTE] Release Qpid Proton 0.11.1

On Tue, 2015-12-15 at 19:32 +, Robbie Gemmell wrote: > Hi all, > > I have put up an RC for 0.11.1, please test it and vote accordingly. +1 > > The release archive and sig/checksums can be grabbed from: > https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.1-rc1/ > > Maven artifacts

Re: Extending the lease duration on messages received with Proton?

On Mon, 2015-12-07 at 10:29 +, Robbie Gemmell wrote: > On 4 December 2015 at 19:56, Philippe Le Rohellec > wrote: > > I'm using Proton to receive messages from an Azure Service Bus > > queue. > > The receiver keeps a lock on each message it receives for a > > predefined >

Re: Acknowledging received messages with Proton and an Azure Service Bus queue

On Fri, 2015-12-04 at 12:20 -0700, plerohel wrote: > Thanks James, that article is extremely helpful. > After I set the messenger incoming_window to a positive value, > messages do > get acknowledged as expected. > Rejecting the message doesn't work though. It might be because I'm > not > setting

Re: Function pn_message_encode() returns -2

traverse is intended to walk the data structure from the beginning. Node "1" is the first child node (node 0 is the "root" of the tree). Nodes are referred to by number rather than pointer because the node storage can be re-allocated if the pn_data object grows which changes the node addresses. So

Re: Question on the information contained in a flow event

On Mon, 2015-11-09 at 13:49 +, Marinov, Vladimir wrote: > Hello all, > > We are implementing AMQP support in our messaging server and for that > purpose we use Proton-j 0.9.1. I'm currently trying to implement > transactional acquisition and I'm stuck with the following: > When a client tries

Re: pn_error_code() returning -2 error

On Mon, 2015-11-09 at 17:12 +0530, Sanny wrote: > Hi, > > Using Proton C library. > > I am following the demo example "send.c" shared in the archive. > Currently > using the mqx OS. > > > 1. I have following function in *pn_error_code*(messenger->error); > always > returning *-2*. while

Re: Proton 0.11.0 release update - The release candidate

On Tue, 2015-11-03 at 22:15 -0500, Justin Ross wrote: > Hi, all. The RC is now available here: > > https://dist.apache.org/repos/dist/dev/qpid/proton/0.11.0-rc/ > > Maven staging repo: > > https://repository.apache.org/content/repositories/orgapacheqpid-10 > 48/ > > I will be away from my

Re: pn_error_code() returning -2 error

On Mon, 2015-11-09 at 17:12 +0530, Sanny wrote: > Hi, > > Using Proton C library. > > I am following the demo example "send.c" shared in the archive. > Currently > using the mqx OS. > > > 1. I have following function in *pn_error_code*(messenger->error); > always > returning *-2*. while

Re: Question on the information contained in a flow event

On Mon, 2015-11-09 at 17:17 +, Robbie Gemmell wrote: > On 9 November 2015 at 17:09, aconway <acon...@redhat.com> wrote: > > On Mon, 2015-11-09 at 13:49 +, Marinov, Vladimir wrote: > > > Hello all, > > > > > > We are impleme

Re: Several queues on direct proton receiver?

On Wed, 2015-11-04 at 23:47 +0300, Michael Ivanov wrote: > Hallo, > > I have a question about direct message receive in proton. > > I tried to receive messages directly using amqp://~1.2.3.4 url. > It works but it seems that queue names in this case are ignored. > I.e. when I subscribe to

Configured proton repo for reviewboard

Added .reviewboardrc configuration file so a simple `rbt post` on a branch will post a review to the Apache reviewboard. See `rbt --help` for more details. Tips: rbt post # Create a new review of current branch with diff against master rbt post --parent branchx # Review with diff

The Go electron API: a tale of two brokers.

The Go binding for proton provides 2 alternate APIs, `proton` is an exact analogue of the event-driven proton C API and `electron` which is a more go-oriented, procedural API. The differences were motivated by the concurrency features of the Go language but there may be lessons to learn for other

The un-reactor

The proton reactor provides a complete solution for integrating foreign IO into a single threaded proton event loop. This is useful in situations where proton is being used in isolation, there is no other IO handling framework available and everything is single threaded. However often that is not

Re: PN_REACTOR_QUIESCED

bvious how this constant was chosen. > > > > With circular reasoning. > > > > > > > > > > > > - Original Message - > > > On Mon, 2015-10-12 at 16:05 -0400, aconway wrote: > > > > ... > > > > +1, that looks like the right fix. 3141 is an

Re: ractor - sending message

On Tue, 2015-10-13 at 14:28 +0200, Tomáš Šoltys wrote: > All right, I think I am finally cracking it. > > Please correct me if I am wrong. > > PN_LINK_FLOW is not meant for sending but for "Updates the flow state > for > the specified link." as stated in specification (2.7.4 Flow - OASIS >

Re: PN_REACTOR_QUIESCED

On Sat, 2015-10-10 at 10:57 +0200, Bozo Dragojevic wrote: > Hi Alan, Rafael, > > On 9. 10. 15 21.25, aconway wrote: > > I'm fiddling with the C++ example broker, and when I install a > > debug > > handler, I see that when the broker

PN_REACTOR_QUIESCED

I'm fiddling with the C++ example broker, and when I install a debug handler, I see that when the broker is doing absolutely nothing there is a PN_REACTOR_QUIESCED event about every 3 seconds. Does anybody know what this is about? Why is the reactor waking up just to tell us that it is asleep?

Default error behavior in event-driven APIs (was Re: Error detection/handling)

On Wed, 2015-09-16 at 14:04 +0200, Tomáš Šoltys wrote: > Hi, > > I have a client that sends a messages to broker. It can happen that > message > contains incorrect subject which will trigger ACL deny on the broker. > But on the client side everything seems to be OK. > > How do I detect such

Re: Proton-996: Surfacing SASL mechanisms into Messenger API

On Mon, 2015-09-21 at 11:35 -0400, Andrew Stitcher wrote: > I worked on PROTON-996[1] last week, and added a new C API which > surfaced the allowed SASL mechanism into the Proton Messenger API. > > For simplicity I added a new API pn_messenger_sasl_allowed_mechs() > which just mirrored the

Create new proton components: go-binding and cpp-binding

I'd like to create these two components, who can edit the project? I can be owner for go-binding, cjansen should probably be owner for cpp -binding. Cheers Alan.

Go binding for proton

I've pushed the Go binding to master, read all about it at https://github.com/apache/qpid-proton/blob/master/proton-c/bindings/go/ README.md The documentation needs a lot of work but you can check the examples and start playing with the code now. Please ignore the packages go/amqp,

Re: Bug in proton interop suite??

t;hello", but what I see is a vbin containing *the AMQP string encoding* of the string hello - i.e. a 7 byte binary sequence with the typecode for AMQP string + the length 5 + the bytes "hello" > > ----- Original Message - > > From: "aconway" <acon...@redhat.

Re: Linker errors with C++ examples

On Wed, 2015-09-09 at 15:07 -0400, Chuck Rolke wrote: > I get the same error with VS2012. Taking a look now... > > - Original Message - > > From: "Clemens Vasters" > > To: proton@qpid.apache.org > > Sent: Wednesday, September 9, 2015 2:39:03 PM > > Subject: Linker

Bug in proton interop suite??

I'm doing some interop work on the go binding, and I see something strange in the 'message.amqp' file in tests/interop. The message body is encoded as: 0x77, 0xa0, 0x7, 0xa1, 0x5, 0x68, 0x65, 0x6c, 0x6c, 0x6f ^ AMQP value section ^Binary ^7 bytes ^String

C++ binding update - moving to master this week.

I have updated the C++ proton binding, for details see: http://people.apache.org/~aconway/proton/c-and-cpp.html http://people.apache.org/~aconway/proton The highlights of the change: - 0 overhead C++ facade classes, facade pointers point directly at C structs. - proton::counted_ptr

Re: A case in favor of separate repos for language bindings

My 2c. The use python to drive C and Java tests was a good idea at the time (because we only had C, Java and Python and python is the most productive language to write tests in) and has served us well, but we have outgrown it. There are two things we need: - good unit tests for each

Re: Final (maybe really) proposal for C++ binding memory management.

pn_shared_ptrT(give()); } operator std::auto_ptrT() { return std::auto_ptrT(give()); } #if PN_USE_CPP11 // FIXME aconway 2015-08-21: need weak pointer context for efficient shared_ptr operator std::shared_ptrT() { return std::shared_ptrT(give()); } operator std::unique_ptrT() { return std

Re: All about proton memory management (or C++, python and Go - Oh My!)

On Wed, 2015-08-19 at 10:45 -0400, Ken Giusti wrote: Nicely done Alan! One point - I'm a little confused about your advice regarding pn_object_decref: The proton C API has standard reference counting rules (but see [1] below) * A pointer returned by a pn_ function is either

Re: All about proton memory management (or C++, python and Go - Oh My!)

On Tue, 2015-08-18 at 12:09 -0400, Andrew Stitcher wrote: On Tue, 2015-08-18 at 07:38 -0400, Rafael Schloming wrote: Nice writeup! I agree. Andrew [Did you make a pass through the doc to ensure that the claimed API doc is actually there? that is, doc on ownership and scope?] No,

Re: Integrating C++ and proton C memory management UPDATED

std::unique_ptrT() const { return std::unique_ptrT(incref(), pn_object_decref); } #endif #if PN_USE_BOOST operator boost::shared_ptrT() const { return boost::shared_ptrT(incref(), pn_object_decref); } operator boost::intrusive_ptrT() const { TODO; } #endif // FIXME aconway 2015-08-17

Re: Integrating C++ and proton C memory management UPDATED

- C++ can use *either* (or boost shared/intrusive pointers) seamlessly if we say that all C++ smart pointers own a *proton reference*, not a *proton object*. Will have another proposal out shortly to clarify. On Sat, 2015-08-15 at 06:09 -0400, aconway wrote: In case you spotted the bug

All about proton memory management (or C++, python and Go - Oh My!)

I've been doing a lot of thinking about memory management and proton bindings in 4 languages (C, Go, python and C++) and I have Seen The Light. Here is a write-up, I'd appreciate feedback in the form of email, reviewboard diffs, regular diffs, or just commit improvements if you're a commiter. I

Re: Integrating C++ and proton C memory management UPDATED

. On Fri, 2015-08-14 at 20:52 -0400, aconway wrote: I have a proposal to integrate C++ and proton C memory management, I need a sanity check. Attached is an executable C++ sketch and test (pn_ptr.cpp) and a script (test.sh) that runs the combinations of g++/clang++ and c++11/c++03

C++ API tutorial complete

The C++ tutorial and examples are complete, except for selector and browsing examples which we can fill in later. Preview at: http://people.apache.org/~aconway/proton/ The code is on branch cjansen_cpp_client

Re: Semantics of proton refcounts [was Re: proton 0.10 blocker]

On Thu, 2015-07-16 at 15:11 +0100, Gordon Sim wrote: On 07/16/2015 02:40 PM, aconway wrote: The fix mentioned above has this, which make no sense under traditional refcounting: pn_incref(endpoint); pn_decref(endpoint); Note that this is not added as part of my

Proton reactor documentation

I'm documenting the C++ binding but the proton C reactor.h is very light on documentation. Is anyone working on this? I'm figuring it out from source but it would be good to have some docs there. Cheers, Alan.

Re: Git repo for the proton Go binding.

On Mon, 2015-07-13 at 23:02 +0100, Dominic Evans wrote: -aconway acon...@redhat.com wrote: - I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go

Re: Tutorial for C++ binding

On Tue, 2015-07-14 at 10:07 +0100, Gordon Sim wrote: On 07/13/2015 11:22 PM, aconway wrote: I've got a (very rough, very incomplete) draft of the tutorial for the C++ binding up on http://people.apache.org/~aconway/proton/ I'm interested in feedback on whether this is going

Re: Git repo for the proton Go binding.

Problem solved, thanks Dominic!! On Mon, 2015-07-13 at 23:02 +0100, Dominic Evans wrote: -aconway acon...@redhat.com wrote: - I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos

FYI: updated C++ tutorial

C++ tutorial is mostly done, if that interests you http://people.apache.org/~aconway/proton/ or check out cjansen-cpp-client.

Re: Git repo for the proton Go binding.

On Mon, 2015-07-13 at 18:28 +0100, Robbie Gemmell wrote: On 13 July 2015 at 16:23, aconway acon...@redhat.com wrote: On Mon, 2015-07-13 at 13:03 +0100, Robbie Gemmell wrote: I don't really know much about Go, so I mainly have questions rather than answers. - What would actually

Re: Git repo for the proton Go binding.

to do this (esp. anyone who's done Go work) I'd be happy to go over the issues in painful detail. On 10 July 2015 at 16:34, aconway acon...@redhat.com wrote: I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based

Tutorial for C++ binding

I've got a (very rough, very incomplete) draft of the tutorial for the C++ binding up on http://people.apache.org/~aconway/proton/ I'm interested in feedback on whether this is going in the right direction. Hope to have this complete in a day or two, along with more substantial API doc for the C

Git repo for the proton Go binding.

I would like to create a separte git repo for the proton Go binding. Go provides go get to grab online go source libraries, based on cloning repos. The go tools assume that each go project has its own repo. I have tried to make this work directly from the proton repo but it is a mess and doesn't

New python tox tests failing on fedora 22, Python 2.7.10/3.4.2

: /home/aconway/proton/proton-c/bindings/python/setup.py py26 create: /home/aconway/proton/proton-c/bindings/python/.tox/py26 ERROR: InterpreterNotFound: python2.6 py27 inst-nodeps: /home/aconway/proton/proton -c/bindings/python/.tox/dist/python-qpid-proton-0.10.0.zip py27 runtests: PYTHONHASHSEED

Re: New python tox tests failing on fedora 22, Python 2.7.10/3.4.2

On Fri, 2015-07-10 at 10:34 -0400, Ted Ross wrote: I had a similar error, not sure if it was exactly the same. I discovered that I was missing the python3-devel package. Once python3-devel was installed and I did a completely clean build, the problems went away. I have that - are you

Re: New python tox tests failing on fedora 22, Python 2.7.10/3.4.2

On Fri, 2015-07-10 at 11:53 -0400, Ken Giusti wrote: - Original Message - From: aconway acon...@redhat.com To: proton proton@qpid.apache.org Sent: Friday, July 10, 2015 10:01:14 AM Subject: New python tox tests failing on fedora 22, Python 2.7.10/3.4.2 Anyone seeing

Re: ProtonJ compilation and test failures

On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote: On 07/06/2015 04:08 PM, Rafael Schloming wrote: Any sort of missing class really should be a compile time exception, which I think means you must have stale class files *somewhere*. You could try doing a find checkout -name *.class

Re: ProtonJ compilation and test failures

On Mon, 2015-07-06 at 17:31 +0100, Gordon Sim wrote: On 07/06/2015 05:22 PM, aconway wrote: On Mon, 2015-07-06 at 16:48 +0100, Gordon Sim wrote: On 07/06/2015 04:08 PM, Rafael Schloming wrote: Any sort of missing class really should be a compile time exception, which I think

Re: ruby test failures on master?

On Wed, 2015-06-24 at 13:53 -0400, aconway wrote: On Wed, 2015-06-24 at 08:10 -0400, Rafael Schloming wrote: Is anyone else seeing the ruby tests fail on master? I've attached the test output. --Rafael Seeing the same thing on fedora 22. I had a quick look and it appears like

Re: ruby test failures on master?

f965610 NO-JIRA: Fix broken ruby build. Swig changes may require clean rebuild. On Thu, 2015-06-25 at 11:33 -0400, aconway wrote: On Wed, 2015-06-24 at 13:53 -0400, aconway wrote: On Wed, 2015-06-24 at 08:10 -0400, Rafael Schloming wrote: Is anyone else seeing the ruby tests fail

Re: ruby test failures on master?

On Wed, 2015-06-24 at 08:10 -0400, Rafael Schloming wrote: Is anyone else seeing the ruby tests fail on master? I've attached the test output. --Rafael Seeing the same thing on fedora 22. I had a quick look and it appears like somebody started to re-organize the namespaces in the ruby

Re: Can we release proton 0.10? Can we add Py3K to that release?

On Tue, 2015-06-16 at 23:38 -0400, Rafael Schloming wrote: I'd like to get the proton-j-reactor branch into 0.10 also. It should be ready soon, so if py3k can be sorted and merged in a similar timeframe we could target a release for the end of the month. The C++ and Go bindings are also

Re: Proton-c Null Messages

On Thu, 2015-06-11 at 14:45 +0100, Gordon Sim wrote: On 06/11/2015 01:54 PM, aconway wrote: On Thu, 2015-06-11 at 13:40 +0100, Gordon Sim wrote: If a name field is populated with an empty string, that to me is the same as not supplying a name. An empty string is a legal encoding

Re: Proton-c Null Messages

On Wed, 2015-06-10 at 16:32 +0100, Gordon Sim wrote: On 06/10/2015 04:01 PM, aconway wrote: On Tue, 2015-06-09 at 19:54 +0100, Gordon Sim wrote: On 06/09/2015 06:40 PM, logty wrote: When I run the client I get: [0x5351db0]:0 - @transfer(20) [handle=0, delivery-id=0

Re: Proton-c Null Messages

On Thu, 2015-06-11 at 13:40 +0100, Gordon Sim wrote: On 06/11/2015 01:11 PM, aconway wrote: I disagree. An empty string is a perfectly legal value for a string. If the spec wants to assign special meaning to particular values of a property that needs to be stated. Of course, like you, I

C++ binding stream encoder/decoder - review requested.

The new commits are on the pull request https://github.com/apache/qpid-proton/pull/35/commits PROTON-865: Stream like Encoder/Decoder and AMQP Value type for C++ binding. See Encoder.h, Decoder.h, Value.h for details. Encoder/Decoder use operator and to encode/decode AMQP values. Value is a

Re: C++ binding naming conventions: Qpid vs. C++

On Tue, 2015-06-09 at 19:56 +0100, Gordon Sim wrote: On 06/09/2015 07:47 PM, aconway wrote: C++ standard library uses lowercase_and_underscores, but Qpid C++ projects to date use JavaWobbleCaseIndentifiers. Is the C++ binding the time to start writing C++ like C++ programmers

Re: C++ binding naming conventions: Qpid vs. C++

with a clear naming convention so I'm strongly tempted to go that way. - Original Message - From: aconway acon...@redhat.com To: proton proton@qpid.apache.org Sent: Tuesday, June 9, 2015 2:47:06 PM Subject: C++ binding naming conventions: Qpid vs. C++ C++ standard library

Re: something rotten in the state of... something or other

On Tue, 2015-06-09 at 17:38 +0100, Robbie Gemmell wrote: I'm not seeing that currently, but I have seen similar sort of things a couple of times in the past. As you mention, some files get created in the source tree (presumably by or due to use of Jython), outwith the normal build areas they

Re: Proton-c Null Messages

On Tue, 2015-06-09 at 19:54 +0100, Gordon Sim wrote: On 06/09/2015 06:40 PM, logty wrote: When I run the client I get: [0x5351db0]:0 - @transfer(20) [handle=0, delivery-id=0, delivery -tag=b, message-format=0, settled=true, more=true] (16363) \x00Sp\xc0\x07\x05B... My guess would

Re: [Resending] - Proton-J engine and thread safety

On 10 Jun 2015, at 16:50, aconway acon...@redhat.com wrote: On Wed, 2015-06-10 at 09:34 +, Kritikos, Alex wrote: [Resending as it ended up in the wrong thread] Hi all, is the proton-j engine meant to be thread safe? The C engine is definitely NOT meant to be thread safe

C++ binding naming conventions: Qpid vs. C++

C++ standard library uses lowercase_and_underscores, but Qpid C++ projects to date use JavaWobbleCaseIndentifiers. Is the C++ binding the time to start writing C++ like C++ programmers? Or will somebody's head explode if class names start with a lower case letter? In particular since the proton C

Re: has someone successfully built proton-c for iOS?

On Sun, 2015-06-07 at 21:28 -0700, yf wrote: We are interested in using Proton-C library in an iOS app so that data can be sent to Qpidd server from iOS app. However, it seems that we can hardly find relevant materials for using Proton-C in an iOS app? We find some Proton introduction

Re: C++ versions for the C++ binding

On Mon, 2015-06-08 at 09:27 +0200, Tomáš Šoltys wrote: Hi, since I need to compile proton on OpenVMS which does not support C++11 nor C++14 I would be more happy with C++03. Thanks, I suspected there would be people out there :) So I'll go for plain ole C++03 to start with, if I add

C++ versions for the C++ binding

I think this has been discussed before, but is there a consensus on what C++ version we want to target for the C++ binding? C++03 is old and smelly. C++11 is better, C++14 better still and afaik any compiler that does 11 will do 14. So the sensible choices would seem to be: 1. Smelly C++03 code

Re: question about proton error philosophy

On Mon, 2013-09-16 at 13:23 -0400, Rafael Schloming wrote: FYI, as of 0.5 you should be able to use pn_messenger_error(pn_messenger_t *) to access the underlying error object (pn_error_t *) and clear it if an error has occurred. Making the application clear errno is pretty standard Unix