On 09/06/2012 05:44 PM, William Henry wrote:
----- Original Message -----
In order to make sure that it can be done, I'm attempting to use
Proton-c in a multi-threaded server environment.The basic assumptions
that I'm making are:
1. The root data structure that threads can operate on is
pn_connector_t/pn_connection_t. An application thread cannotuse
pn_driver_t without taking measures to ensure that it is the only
one doing so at a time.
2. As long as no two threads are concurrently operating on the same
instance of pn_connection_t, everything should work properly.
So far, so good. There is one interesting exception to the above.
It will commonly be the case that a thread processing the reception
of a
message from an inbound link will need to indicate to a different
outbound link that there is now data to be sent (i.e. activate that
link
for write). It is likely that the outbound link will be associated
with
a different connection that the thread is not allowed to use because
another thread may be processing it concurrently.
FYI, I had to deal with this with the OpenMAMA integration work. The publisher
example program also has a reply queue and so subscribes for incoming messages.
To be safe I had to use two pn_messenger_t instances, one for the outbound and
one for the inbound. It was a bit ugly but because I am listening for replies
on another thread while publishing on the main thread I wasn't sure what else I
could do until Proton handled multiple threads.
This is not difficult to handle, but it requires that my threading
layer
be able to get the pn_connector_t associated with the link. Proton-c
provides the following linkage: pn_link_t => pn_session_t =>
pn_connection_t. There's no way to get the pn_connector_t though.
So, I think I need one of two possible changes:
1. Provide linkage from pn_connection_t to pn_connector_t (may be
architecturally undesirable), or
2. Add a void* context field to pn_connector_t.
Thoughts, Feelings, Emotions?
Whichever way you go I'm presuming that much of this will get hidden underneath
the pn_messenger_t interface.(?)
To be clear, I'm looking at the underpinnings of messaging
intermediaries (brokers, routers, proxies, firewalls, toolkits, etc.)
rather than endpoints. I don't think that pn_messenger_t is relevant in
such environments. However, there's no reason why a multi-threaded
client or server couldn't use the same patterns. There won't be any
benefit unless the endpoint is dealing with multiple connections though.
William
-Ted
