I have gone through the documentation and code and have the following understanding of container vs connection_engine:
Container is an adapter for pn_reactor. The proton reactor manages network IO and sends events to a registered handler so container registers an proxy handler which will pass events to the user's implementation. Connection_engine passes IO to a pn_transport (through io_read and io_write) and receives events through a pn_collector. Dispatching is then done directly to the user handler. >From my understanding connection_engine looks more efficient than the container for the same functionality (if socket_engine is used). It also offers more control since a custom implementation can modify the event loop and mock IO for testing. This makes it a better fit for me compared to the proposed "application event injection" which is proposed in the thread on qpid-users. Am I missing something which is managed by the reactor or the container? Also, the release notes for proton 12 say that the API for container is stable but that connection_engine is still unstable. Will this interface still have the same role in future versions (ie converting IO to proton events) ? Thanks for your help Mark On Fri, Mar 18, 2016 at 11:03 AM, Mark Banner <mark95...@gmail.com> wrote: > I'll look into the connection_engine API then. Thanks for the reply! > > On Thu, Mar 17, 2016 at 9:15 PM, Alan Conway <acon...@redhat.com> wrote: > >> On Thu, 2016-03-17 at 20:02 +0100, Mark Banner wrote: >> > Hi, >> > >> > I am creating an application which is using the C++ API for AMQP >> > (0.12) and >> > I am trying to wrap my head around how to create a sender when I have >> > a new >> > message to send. >> > >> > For receiving messages, I can create a receiver when the container is >> > finished initializing and on_message will be called whenever a new >> > message >> > is received. However, for sending messages, if I create a sender when >> > the >> > reactor initializes, on_sendable will be called when it is not >> > needed. From >> > what I understand in the examples, the a sender should be closed when >> > all >> > the client's messages have been sent. >> > >> > How should I go about telling the container I want to send a message? >> > Is it >> > safe to pass the connection which is set up in on_start outside of >> > the >> > container and to create a new sender in another thread? >> > >> > Any help would be much appreciated, >> > Mark >> >> The container is not thread safe, and it is not safe to use any >> container-owned proton objects outside the thread that calls >> container::run(). Presently there is no way to stop it running. This is >> a very serious limitation. >> >> There is a plan to add "application event injection" which would allow >> you to inject custom actions from arbitrary threads and have them >> executed safely in the container::run() thread. I expect that to >> materialize soon. >> >> There is also an alternative to the container: the connection_engine. >> It gives you full control over how IO and threads interact with proton. >> Right now it is raw but usable (see the cpp/engine examples.) It is my >> top priority to make this easy to use for all the common multi-threaded >> use cases. I would be happy to help you use it and to be guided by your >> use cases in developing it for the future. >> >> Cheers, >> Alan. >> >> >
