ffrenchm wrote:
Gordon Sim wrote:
ffrenchm wrote:
Where are the options to have synchronous / asynchronous IO ?
That option is no longer supported. The store will always use
asynchronous IO for recording the enqueue/dequeue of messages (bdb is
really only used to record exchanges, bindings and other config).
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 ?
Asynchronous IO means that the write is not blocked until the data is on
disk, allowing the broker to start writing the next message immediately
and improving the throughput. However safety is still important as you
point out and the store tracks completion of all these asynchronous
writes and the broker will not acknowledge the receipt of the message to
the sending client until the store confirms that the message has reached
the disk.
I.e. once the broker tells the client it has completed the publication
request, the message is guaranteed to be on the disk.
The client can then independently vary the strategy used to request
information on completion of publications. It can send message
asynchronously, in which case the send method on the api will return
before the broker has fully processed the message (perhaps flushing
regularly to update its record of safe messages). Alternatively it can
request that the send method blocks until the message is confirmed by
the broker. (Or indeed some hybrid of the two).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
