On Fri, Feb 23, 2018 at 5:43 AM, Baptiste Robert <baptisterober...@gmail.com
> wrote:

> Hi everybody,
> I'm struggling a little bit with the global architecture of proton cpp. I'm
> trying to code a wrapper to simplify the utilization for a end user.
> This wrapper is divided in two classes, a "client" that launch the
> proton::container in a separate thread, and a handler that inherate
> proton::messaging_handler. My "client" part is supposed to allow the user
> to create a new connection, send message, close the connection, etc..
> But I encounter strange behavior from proton, like why when I called a
> close on a connection, then my container exit from his thread (return from
> the run) ?

Do  you have some sample code? Possibly there is some confusion about the
threading rules. For example to close a connection from a thread other than
the event handling thread, you need to use a work-queue.
Have you looked at the cpp/multithreaded_* examples?

Same issue with the proton::reconnection_options, it does not works
> properly, if I simulate a broker crash and then relaunch it, my connection
> wait while the container is offline but after the restart I get a transport
> error.
It should work - if you can show some sample code we can figure out why

> So I supposed my problem here is that I not fully understand the philosophy
> of proton. In my mind it was : one container that handle multiple
> connections, and the container can close/open connections from different
> thread.
That's correct, although there are some rules about what you can do from
what thread. Take a look at

> Oh and lastly, I do not understand why the proton::error_condition does not
> have an error code (proper enum, not string).

It represents an AMQP error condition which has a name, description and
some optional "info" - not an operating system error. In cases where we
generate error conditions internally because of OS errors we usually
include the OS error description in the description but there's no access
to an OS-specific error code.

The condition name acts a bit like an error "type", but it is not a closed
set. For IO related errors we use "proton:io", there are some AMQP standard
names which can be used for errors on the wire, but an application is free
to invent others:

InternalError         = "amqp:internal-error"
NotFound              = "amqp:not-found"
UnauthorizedAccess    = "amqp:unauthorized-access"
DecodeError           = "amqp:decode-error"
ResourceLimitExceeded = "amqp:resource-limit-exceeded"
NotAllowed            = "amqp:not-allowed"
InvalidField          = "amqp:invalid-field"
NotImplemented        = "amqp:not-implemented"
ResourceLocked        = "amqp:resource-locked"
PreconditionFailed    = "amqp:precondition-failed"
ResourceDeleted       = "amqp:resource-deleted"
IllegalState          = "amqp:illegal-state"
FrameSizeTooSmall     = "amqp:frame-size-too-small"

Reply via email to