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:[email protected]
