[rabbitmq-discuss] Channel Cost

[Ben Hyde]

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  
> or
> connection automatically.

Assuring that all these are raised and caught provides no end of  
amusement.

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  
be wrong.

> 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):
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2008-November/002539.html

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.