[rabbitmq-discuss] Channel Cost

Tue Jan 27 19:25:17 GMT 2009

Ben,

Ben Hyde wrote:
> There doesn't appear to be a way for the server to signal these errors  
> short of tearing down the connection.  So catching this is a matter  
> for your heartbeats or your doing it at the transport layer.  Correct?

The errors are signalled to the client in a {channel,connection}.close 
command. When the client responds to that with an 'ok' (or after a 
timeout) the server closes the underlying tcp connection.

So there is plenty of opportunity for the client to report/signal the 
error. Such notifications are still asynchronous though, since you don't 
get any positive acks that a message has been successfully published.

> interesting:  "issue *any* synchronous command.  The response  
> constitutes a guarantee that all messages published prior  to the  
> request will have been processed by the channel process on the server."
> 
> That seems useful.  If you had the heart beat enabled would that tell  
> you something similar?  Again not interoperable.
> 
> Do you have a synch. cmd you'd recommend.

Heartbeats only tell you whether the other side is still alive. They 
don't tell you what it has seen/processed.

As for what sychronous command to use...

- 'access.request' is the cheap since it's currently a no-op ... pending 
its removal when we implement AMQP 0-9-1.

- 'basic.cancel' with a non-existing consumer tag is very cheap too.

- Another option is 'channel.flow', which for the RabbitMQ server is a 
no-op (until we implement it), and hence cheap.

Note though that getting a confirmation that the RabbitMQ's channel 
processes have handled a message may not provide you enough of a 
guarantee. The messages may not have been enqueued yet (though setting 
the 'mandatory' flag will provide that guarantee), and, in case of 
persistent messages, may not have been flushed to disk yet (nothing you 
can do about that short of using tx.*).

Matthias.