You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Zhihua Che <zh...@gmail.com> on 2012/06/26 15:46:48 UTC
ThreadSafe/Multiple Session/Connection handling
Hi,
I'm employing qpid in my current project and need some tips for
common programming practice.
1, Are Sender/Receiver/Session/Connection thread-safe?
ie, Is it ok for multiple threads to send messages through the
same sender, or to create senders/receivers through the same session.
2, When do I need to create a separate session?
I know it's feasible to create more than one session in one
application/process, but, I wonder when it's reasonable to create two
session, instead of only one.
3, How do I handle the connection lost or sending/receiving failure?
In my application, sending/receiving fails occasionally with an
exception throw. What can I do to fix it and take another try
initiatively at runtime if I refuse to exit the process?
Is it reasonable to open the connection again and create new
senders and receivers to take a new try?
I know there is reconnect option for the Connection. But It cannot
keep connection alive forever, right?
Furthermore, I find qpid client api doesn't offer a connection
pool mechanism, Does that mean I need to implement one by myself if I
want or the connection pool is not recommended?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: ThreadSafe/Multiple Session/Connection handling
Posted by Zhihua Che <zh...@gmail.com>.
2012/6/26 Gordon Sim <gs...@redhat.com>:
> On 06/26/2012 04:24 PM, Zhihua Che wrote:
>>
>> What do you mean by 'you can't retrieve the indoubt messages from a
>> sender on a failed connection'?
>> Do you mean that the message which causes the Sender.send() failure
>> would not be fetched by Receiver.fetch() and 'lost' forever?
>
>
> If you call send() with the synchronous flag set to true then the call will
> block until the message has been confirmed by the broker.
>
> However if you call it with the synchronous flag set to false, then the call
> returns before it has been confirmed by the broker.
>
> When using the reconnect message, any unconfirmed messages are resent when a
> connection is re-established.
>
> However if you disable reconnect and handle the connection failure yourself
> then you would need to also handle any resending. Unfortunately at present
> you can't use the old senders to retrieve the messages to be resent. (You
> can determine how many of them remained unconfirmed, you just can't get the
> messages back themselves).
>
>
>> By the way, I wonder why the Receiver.fetch() could throw
>> NoMessageAvailable because I thought the function would just block
>> until message is available or the timeout is due.
>
>
> It does. It will only throw NoMessageAvailable once the requested timeout
> has expired and there is still no message. Note also that the exception is
> only used for the second form of the fetch() method. The first form returns
> a boolean indicating whether a message was fetched or not (if true, the
> reference passed in now refers to that message). The second form returns a
> message if available and throws if not. You can use whichever style you
> prefer,
>
>
>
>
Thanks for your patience:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: ThreadSafe/Multiple Session/Connection handling
Posted by Gordon Sim <gs...@redhat.com>.
On 06/26/2012 04:24 PM, Zhihua Che wrote:
> What do you mean by 'you can't retrieve the indoubt messages from a
> sender on a failed connection'?
> Do you mean that the message which causes the Sender.send() failure
> would not be fetched by Receiver.fetch() and 'lost' forever?
If you call send() with the synchronous flag set to true then the call
will block until the message has been confirmed by the broker.
However if you call it with the synchronous flag set to false, then the
call returns before it has been confirmed by the broker.
When using the reconnect message, any unconfirmed messages are resent
when a connection is re-established.
However if you disable reconnect and handle the connection failure
yourself then you would need to also handle any resending. Unfortunately
at present you can't use the old senders to retrieve the messages to be
resent. (You can determine how many of them remained unconfirmed, you
just can't get the messages back themselves).
> By the way, I wonder why the Receiver.fetch() could throw
> NoMessageAvailable because I thought the function would just block
> until message is available or the timeout is due.
It does. It will only throw NoMessageAvailable once the requested
timeout has expired and there is still no message. Note also that the
exception is only used for the second form of the fetch() method. The
first form returns a boolean indicating whether a message was fetched or
not (if true, the reference passed in now refers to that message). The
second form returns a message if available and throws if not. You can
use whichever style you prefer,
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: ThreadSafe/Multiple Session/Connection handling
Posted by Zhihua Che <zh...@gmail.com>.
2012/6/26 Gordon Sim <gs...@redhat.com>:
> On 06/26/2012 02:46 PM, Zhihua Che wrote:
>>
>> Hi,
>> I'm employing qpid in my current project and need some tips for
>> common programming practice.
>
>
> I'm assuming you are using the c++ client(?) here.
>
I'm using c++ broker and c++/python client.
>> 1, Are Sender/Receiver/Session/Connection thread-safe?
>> ie, Is it ok for multiple threads to send messages through the
>> same sender, or to create senders/receivers through the same session.
>
>
> Yes, but accessing a session concurrently from more than one thread makes it
> hard to reason about sequence in any way. I would myself tend towards using
> a single thread per session unless there was a compelling reason to increase
> that.
>
>
>> 2, When do I need to create a separate session?
>> I know it's feasible to create more than one session in one
>> application/process, but, I wonder when it's reasonable to create two
>> session, instead of only one.
>
>
> I think of a separate session as reflecting a logically distinct
> conversation. If several messages are logically related to a particular
> action for example, then they are probably ideally sent on the same session.
> If you have several such multi-message interactions that are each
> independent of the other, then using separate sessions would likely be a
> good idea. Does this help at all?
>
>
>> 3, How do I handle the connection lost or sending/receiving failure?
>> In my application, sending/receiving fails occasionally with an
>> exception throw. What can I do to fix it and take another try
>> initiatively at runtime if I refuse to exit the process?
>> Is it reasonable to open the connection again and create new
>> senders and receivers to take a new try?
>
>
> Yes, you can do that. Unfortunately at present you can't retrieve the
> indoubt messages from a sender on a failed connection (if reconnect is
> enabled those would be resent for you automatically on reconnecting).
>
What do you mean by 'you can't retrieve the indoubt messages from a
sender on a failed connection'?
Do you mean that the message which causes the Sender.send() failure
would not be fetched by Receiver.fetch() and 'lost' forever?
By the way, I wonder why the Receiver.fetch() could throw
NoMessageAvailable because I thought the function would just block
until message is available or the timeout is due. I mean it doesn't
make sense to throw an exception if there is no available message
right now.
>
>> I know there is reconnect option for the Connection. But It cannot
>> keep connection alive forever, right?
>
>
> You can configure how the reconnect works (e.g. how many times it will
> retry, how long it will wait for etc) through the connection options.
>
>
>> Furthermore, I find qpid client api doesn't offer a connection
>> pool mechanism, Does that mean I need to implement one by myself if I
>> want or the connection pool is not recommended?
>
>
> You would need to implement one yourself I'm afraid.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: ThreadSafe/Multiple Session/Connection handling
Posted by Gordon Sim <gs...@redhat.com>.
On 06/26/2012 02:46 PM, Zhihua Che wrote:
> Hi,
> I'm employing qpid in my current project and need some tips for
> common programming practice.
I'm assuming you are using the c++ client(?) here.
> 1, Are Sender/Receiver/Session/Connection thread-safe?
> ie, Is it ok for multiple threads to send messages through the
> same sender, or to create senders/receivers through the same session.
Yes, but accessing a session concurrently from more than one thread
makes it hard to reason about sequence in any way. I would myself tend
towards using a single thread per session unless there was a compelling
reason to increase that.
> 2, When do I need to create a separate session?
> I know it's feasible to create more than one session in one
> application/process, but, I wonder when it's reasonable to create two
> session, instead of only one.
I think of a separate session as reflecting a logically distinct
conversation. If several messages are logically related to a particular
action for example, then they are probably ideally sent on the same
session. If you have several such multi-message interactions that are
each independent of the other, then using separate sessions would likely
be a good idea. Does this help at all?
> 3, How do I handle the connection lost or sending/receiving failure?
> In my application, sending/receiving fails occasionally with an
> exception throw. What can I do to fix it and take another try
> initiatively at runtime if I refuse to exit the process?
> Is it reasonable to open the connection again and create new
> senders and receivers to take a new try?
Yes, you can do that. Unfortunately at present you can't retrieve the
indoubt messages from a sender on a failed connection (if reconnect is
enabled those would be resent for you automatically on reconnecting).
> I know there is reconnect option for the Connection. But It cannot
> keep connection alive forever, right?
You can configure how the reconnect works (e.g. how many times it will
retry, how long it will wait for etc) through the connection options.
> Furthermore, I find qpid client api doesn't offer a connection
> pool mechanism, Does that mean I need to implement one by myself if I
> want or the connection pool is not recommended?
You would need to implement one yourself I'm afraid.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org