[rabbitmq-discuss] AMQP library APIs
alan.antonuk at gmail.com
Wed Aug 7 23:32:20 BST 2013
On Wed, Aug 7, 2013 at 2:43 PM, Michael Klishin <mklishin at gopivotal.com>wrote:
> Bunny's automatic recovery is for network failures, not connection
> exceptions (which are rare
> and severe, and should be as visible as possible).
I agree with you on the connection exceptions, in that case it makes a lot
of sense to be loud. However I was thinking in the case of a channel
exception being thrown. E.g., you have a consumer associated with a
channel, and you happen to publish to a non-existent exchange, whoops that
consumer goes away. Obviously the client code should be notified of the
failure, but from an API perspective its annoying to have something that is
potentially unrelated be affected and have to be recreated.
> I don't think this is a good idea. First, it is part of the protocol
> and developers may want to use that. Second, error handling for operations
> such as queue.declare
> or basic.publish, is per-channel. Finally, basic.qos setting, delivery
> tags and publisher confirms
> are all per-channel.
That makes me wonder what is it that developers use channels for? My
understanding is they're were designed to be an 'error scope' at a protocol
level. I don't see a lot of developers using them that way, and sometimes
its the source of a bit of pain (having to recreate any resources that get
destroyed as a result of a channel exception, or in bad cases, their whole
app aborts because the channel dies).
My thinking is that an API could be created that internally uses channels
intelligently to give more native feel to error handling. One example of
changing the API might be: instead of apply basic.qos to a channel, you
apply it to a consumer, and internally the library maps a consumer to a
channel, so a BasicQos on a consumer. The same can be done for other
aspects of the protocol (this is what I ended up doing with
SimpleAmqpClient). A downside being the API may not map 1:1 to a lot of
the documentation that is out there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss