Mailing-List: contact users-help@qpid.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@qpid.apache.org
Received-SPF: pass (nike.apache.org: domain of
 lists+1231964187411-2158936@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Message-ID: <1235408424478-2373080.post@n2.nabble.com>
Date: Mon, 23 Feb 2009 09:00:24 -0800 (PST)
From: ffrenchm <ffrench.mathilde@gmail.com>
To: users@qpid.apache.org
Subject: Re: QPID C++ Broker + persistent store
In-Reply-To: <49A2D25E.50006@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <1235403934162-2372671.post@n2.nabble.com>
 <49A2C6EF.3020200@redhat.com> <1235405284419-2372777.post@n2.nabble.com>
 <49A2CAE7.2060607@redhat.com> <1235407413149-2372992.post@n2.nabble.com>
 <49A2D25E.50006@redhat.com>


I'm currently working on a JMS client. I suppose that the equivalent of C++
async session is a DUPS_OK_ACKNOWLEDGE session (I'm not sure) ...

++


Carl Trieloff wrote:
> 
> 
> yes, for example in c++ there is a sync and async session. The async one 
> return after calling and
> allows another message to be sent. Errors or handled async. sync session 
> blocks on the call.
> 
> The sync / flush commands can be used to control this yourself if you want
> 
> This type of thing can be done from any client, which client do you care 
> about?
> Carl.
> 
> 
> ffrenchm wrote:
>> Ok I understand your answer, but it raise me another question :) Is there
>> a
>> way to have a really asynchronous client/server communication when
>> putting
>> messages ? I mean the client send a message and then the server ack the
>> client without waiting that the message is on the disk ?
>>
>> Thanks ...
>>
>>
>> Carl Trieloff wrote:
>>   
>>>     
>>>> Well, I do not understand why the synchronous IO mode is no longer
>>>> supported. My experiences of queueing tell me that if you want really
>>>> safe
>>>> message store you need synchronous IO on message PUT. But maybe did I
>>>> miss
>>>> some new things which make this feature deprecated ?
>>>>
>>>>   
>>>>       
>>> This is a great question:
>>>
>>> The key is that the C++ broker is that it is an async process, so the 
>>> broker has all the logic to know when all the async processing on a 
>>> message is complete. So even with a async store, the broker will not ack 
>>> the client until the message/update is physically written to disk. Given 
>>> this there is no advantage to a sync mode. Async is faster in all cases 
>>> - and all the exact same message guarantees are provided using  async.
>>>
>>> The only reason the sync option was there was to enable testing while 
>>> the async impl was been hardened.
>>>
>>> regards
>>> Carl.
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:      http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>>
>>>     
>>
>>   
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/QPID-C%2B%2B-Broker-%2B-persistent-store-tp2372671p2373080.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org