[rabbitmq-discuss] Channel Cost
bhyde at pobox.com
Tue Jan 27 17:07:35 GMT 2009
Is there a more appropriate venue for AMQP users to gather and puzzle
out what's what? I feel a lack of community around my attempts to
puzzle out what design patterns are good, and what AMQP expects of me.
On Jan 26, 2009, at 9:25 PM, Jason J. W. Williams wrote:
> ... you can't pickup errors from a basic_publish in
> py-ampqlib until you close the channel ...
One thing I'm having trouble with is getting a clear model of how
responsibility for a message moves around. Basic publish tosses
responsibility, and it's - ah - later that you _might_ infer or be
told that it didn't work out.
That is the point of "2.2.3 No Confirmations" in "Advanced Message
Queuing Protocol Specification [0.8 June 2006]".
On Jan 27, 2009, at 4:13 AM, Matthias Radestock wrote:
> What do you mean by "errors"?
indeed ... great list!
> There are two types of errors that can
> arise when the server processes a basic.publish command. AMQP errors,
> such as malformed requests, missing exchange, etc, close the channel
> connection automatically.
Assuring that all these are raised and caught provides no end of
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?
> Routing failures of messages with the
> 'mandatory' or 'immediate' flag are signalled to the client with an
> asynchronous basic.return command.
> Are you saying that in py-amqplib there is no way to get hold of the
> latter until channel closure?
If I'm reading the code correctly the client (next time it reads from
the channel) will dispatch to the basic_return method of the Channel
object. The Channel class does not have that method defined. I could
> If so that would seem to be an omission in
> the library and I suggest you take that up with the authors.
True that. Crosstalk is good. Py-amqplib is an important complement
to rabbitmq. There isn't a py-ampqlib mailing list, correct?
On Jan 27, 2009, at 10:24 AM, Dmitriy Samovskiy wrote:
> Could this suggestion by Matthias help you (second to last paragraph):
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.
More information about the rabbitmq-discuss