On 04/15/2014 01:53 PM, Rob Godfrey wrote:
From an AMQP 1.0 perspective, the broker really shouldn't need telling.
The question is really how to determine if/when the broker should flush
any writes to disk. Durable messages will only be considered settled
when the broker can be sure the enqueue is recorded.
In processing a stream of messages flushing every enqueue individually
would perform poorly. The current store plugin (on linux) will flush
each 'page' when it fills up.
However if the client session won't send any further messages, then an
explicit flush makes sense, so that the disposition can be more speedily
communicated. At present, the store will periodically flush itself, but
that of course leaves the client waiting for the next automatic flush
before it gets its dispositions.
I guess you could use the lack of any data to read on the socket as a
hint to flush. If you had concurrent sessions it would need to be a bit
more subtle than that.
At present the c++ broker is structured as a general IO layer that does
the socket IO and protocol specific connection implementations (engines
effectively) that handle the incoming bytes. The absence of further data
isn't directly communicated (it could perhaps be inferred at least in
some cases from the size of data available to decode).
The intention was that a container may decide to batch information it has
on hand, but it should always be "prompt" in informing its peers of
disposition changes. So its valid to wait until you've finished process a
batch of incoming stuff before generating an optimised set of disposition
state, but not to hold onto the data on the hope of hearing more at some
indeterminate point in the future and only informing your partner of the
dispositions at that time.
-- Rob
On 15 April 2014 14:44, Pavel Moravec <[email protected]> wrote:
Hello,
I have spotted a performance-impacting lack in AMQP 1.0 implementation of
session.sync() in C++ client. On AMQP 0-10, the method sends execution.sync
frame to the broker, asking for prompt delivery status to be sent. But 1.0
client does not invoke any such command. For performance impact, see
QPID-5701 I raised.
My question is: what would be reasonable way of telling the broker "please
send me all dispositions now" over AMQP 1.0? Any ideas? Checking AMQP 1.0
spec I dont see a direct way..
Kind regards,
Pavel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
