On Fri, Feb 23, 2018 at 5:43 AM, Baptiste Robert <[email protected] > 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 not. > > 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 proton-c/bindings/cpp/docs/mt.md > > 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"
