Re: Creating a sender outside of a container's thread

[Mark Banner]

Thanks Alan.

On Thu, Mar 24, 2016 at 11:02 PM, Alan Conway  wrote:

> On Fri, 2016-03-18 at 16:01 +0100, Mark Banner wrote:
> > 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?
>
> That's an excellent summary.
>
> >
> > 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) ?
>
> Yes. The connection_engine separates just the AMQP features of proton
> without entangling them in any assumptions about IO or threads. It will
> stay as an integration point for users that have special IO/threading
> needs.
>
> The plan is then to layer more convenience on top of the engine for common
> threading and IO use-cases, so users that are happy with a generic
> implementation don't have to start from scratch.
>
> Injecting functions will be a part of the ease-of-use layer for the
> connection engine, but injecting into a specific connection context rather
> than a container of many connections.
>
> These are not untested ideas, they follow from patterns in the qpidd C++
> broker, the qpid dispatch engine and the proton Go binding.
>
> Cheers,
> Alan.
>
>
>
>

Re: Creating a sender outside of a container's thread

[Alan Conway]

On Fri, 2016-03-18 at 16:01 +0100, Mark Banner wrote:
> 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?

That's an excellent summary.

> 
> 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) ?

Yes. The connection_engine separates just the AMQP features of proton
without entangling them in any assumptions about IO or threads. It will
stay as an integration point for users that have special IO/threading
needs.

The plan is then to layer more convenience on top of the engine for common 
threading and IO use-cases, so users that are happy with a generic 
implementation don't have to start from scratch.

Injecting functions will be a part of the ease-of-use layer for the connection 
engine, but injecting into a specific connection context rather than a 
container of many connections.

These are not untested ideas, they follow from patterns in the qpidd C++ 
broker, the qpid dispatch engine and the proton Go binding.

Cheers,
Alan.

Re: Creating a sender outside of a container's thread

[Alan Conway]

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.

Creating a sender outside of a container's thread

[Mark Banner]

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

Re: Creating a sender outside of a container's thread

[Mark Banner]

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  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  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.
>>
>>
>