qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++ sync/async client API (was Re: sync needed in fanout example?)
Date Tue, 27 May 2008 18:37:49 GMT
Gordon Sim wrote:
> Alan Conway wrote:
>> 1. Remove the SYNC/ASYNC paramemter from newSession
>>   Session s = c.newSession(SYNC) --> s = c.newSession()
>>
>> 2. If you want mostly-sync, then fix the async calls:
>>  s.transfer(...) --> async(s).transfer(...)
>>
>> 3. If you want mostly-async then modify the newsession and fix sync 
>> calls:
>>  AsyncSession s = c.newSession()
>>  s.foo(...) --> sync(s).foo
> 
> There is also a subtle impact on some of the 'utility' classes that can 
> be used on top of the Session API. Previously the synchronicity of 
> interactions from these classes would be controlled by the mode on the 
> session, now the behaviour is defined as part of the classes themselves.
> 
> E.g. each SubscriptionManager::subscribe() is always synchronous now, 
> and each message-accept sent by the dispatcher in auto-acking mode is 
> always asynchronous.
> 
> One other point is that setting the sync flag on a command and waiting 
> for it to complete is not in general the same thing as issuing an 
> execution-sync and waiting for that to complete. Though with the current 
> c++ broker both will actually have the same effect, that needn't be the 
> case with other brokers.
> 
> So e.g. in SubscriptionManager::setFlowControl() it would in my view be 
> better to use an explicit sync rather than relying on sync mode for the 
> last command issued.

Done, also added a flush() to sync() so that sync ensures we are up-to-date in 
both directions.

Mime
View raw message