[rabbitmq-discuss] message availability after close without ack

You're understanding is correct - the key part is the channel being
closed.
Hmm. Can you isolate the code that is doing this - it really shouldn't
be happening.

Matthew

Apologies. I shall return to school now to be taught the difference
between your and you're.

Matthew

Tim,
You may want to run your app through the tracer
(http://www.rabbitmq.com/examples.html#tracer), which will produce a
trace much like the above. If you do get a trace that looks wrong please
post it here.

Regards,

Matthias.

Here's the output from the tracer:

1276625968512: conn#0 ch#0 -> {#method<connection.start-ok>(client-properties={},mechanism=AMQPLAIN,response=LOGINSguesPASSWORDSguest,locale=en_US),null,""}
1276625968512: conn#0 ch#0 <- {#method<connection.start>(version-major=8,version-minor=0,server properties={product=RabbitMQ, information=Licensed under the MPL. See http://www.rabbitmq.com/, platform=Erlang/OTP, copyright=Copyright (C) 2007-2010 LShift Ltd., Cohesive Financial Technologies LLC., and Rabbit Technologies Ltd., version=1.7.2},mechanisms=PLAIN AMQPLAIN,locales=en_US),null,""}
1276625968514: conn#0 ch#0 <- {#method<connection.tune>(channel-max=0,frame-max1072,heartbeat=0),null,""}
1276625968557: conn#0 ch#0 -> {#method<connection.tune-ok>(channel-max=0,frame-max1072,heartbeat=0),null,""}
1276625968557: conn#0 ch#0 -> {#method<connection.open>(virtual-host=/,capabilities=,insistúlse),null,""}
1276625968599: conn#0 ch#0 <- {#method<connection.open-ok>(known-hosts¾de:53814),null,""}
1276625968664: conn#0 ch#1 -> {#method<channel.open>(out-of-band=),null,""}
1276625968705: conn#0 ch#1 <- {#method<channel.open-ok>(),null,""}
1276625968749: conn#0 ch#1 -> {#method<exchange.declare>(ticket=0,exchange-fdceee-a20a-4ce9-a897-fd0660e214b5,type=topic,passiveúlse,durable=true,auto-deleteúlse,internalúlse,nowaitúlse,arguments={}),null,""}
1276625968790: conn#0 ch#1 <- {#method<exchange.declare-ok>(),null,""}
1276625968831: conn#0 ch#2 -> {#method<channel.open>(out-of-band=),null,""}
1276625968872: conn#0 ch#2 <- {#method<channel.open-ok>(),null,""}
1276625968915: conn#0 ch#2 -> {#method<queue.declare>(ticket=0,queue‰207d72-4f0e-4b52-87e9-7e13656a3589,passiveúlse,durable=true,exclusiveúlse,auto-deleteúlse,nowaitúlse,arguments={}),null,""}
1276625968956: conn#0 ch#2 <- {#method<queue.declare-ok>(queue‰207d72-4f0e-4b52-87e9-7e13656a3589,message-count=0,consumer-count=0),null,""}
1276625968997: conn#0 ch#2 -> {#method<queue.bind>(ticket=0,queue‰207d72-4f0e-4b52-87e9-7e13656a3589,exchange-fdceee-a20a-4ce9-a897-fd0660e214b5,routing-key=blah,nowaitúlse,arguments={}),null,""}
1276625969038: conn#0 ch#2 <- {#method<queue.bind-ok>(),null,""}
1276625969081: conn#0 ch#2 -> {#method<basic.consume>(ticket=0,queue‰207d72-4f0e-4b52-87e9-7e13656a3589,consumer-tag=,no-localúlse,no-ackúlse,exclusiveúlse,nowaitúlse),null,""}
1276625969122: conn#0 ch#2 <- {#method<basic.consume-ok>(consumer-tag=amq.ctag-iVU1DgfIJCmSSthlatN1JA==),null,""}
1276625969166: conn#0 ch#3 -> {#method<channel.open>(out-of-band=),null,""}
1276625969206: conn#0 ch#3 <- {#method<channel.open-ok>(),null,""}
1276625969251: conn#0 ch#3 -> {#method<basic.publish>(ticket=0,exchange-fdceee-a20a-4ce9-a897-fd0660e214b5,routing-key=blah,mandatoryúlse,immediateúlse),#contentHeader<basic>(content-type=null, content-encoding=null, headers=null, delivery-mode=2, priority=null, correlation-id=null, reply-to=null, expiration=null, message-id=null, timestamp=null, type=null, user-id=null, app-id=null, cluster-id=null),"foo"}
1276625969291: conn#0 ch#2 <- {#method<basic.deliver>(consumer-tag=amq.ctag-iVU1DgfIJCmSSthlatN1JA==,delivery-tag=1,redeliveredúlse,exchange-fdceee-a20a-4ce9-a897-fd0660e214b5,routing-key=blah),#contentHeader<basic>(content-type=null, content-encoding=null, headers=null, delivery-mode=2, priority=null, correlation-id=null, reply-to=null, expiration=null, message-id=null, timestamp=null, type=null, user-id=null, app-id=null, cluster-id=null),"foo"}
1276625969339: conn#0 ch#2 -> {#method<basic.cancel>(consumer-tag=amq.ctag-iVU1DgfIJCmSSthlatN1JA==,nowaitúlse),null,""}
1276625969340: conn#0 ch#4 -> {#method<channel.open>(out-of-band=),null,""}
1276625969380: conn#0 ch#2 <- {#method<basic.cancel-ok>(consumer-tag=amq.ctag-iVU1DgfIJCmSSthlatN1JA==),null,""}
1276625969381: conn#0 ch#4 <- {#method<channel.open-ok>(),null,""}
1276625969421: conn#0 ch#4 -> {#method<basic.consume>(ticket=0,queue‰207d72-4f0e-4b52-87e9-7e13656a3589,consumer-tag=,no-localúlse,no-ackúlse,exclusiveúlse,nowaitúlse),null,""}
1276625969463: conn#0 ch#4 <- {#method<basic.consume-ok>(consumer-tag=amq.ctag-IGMvYJA+e5b1lSzF6TqDcw==),null,""}

At this point, it just waits forever; no basic.deliver arrives. But I'm
noticing that I don't see a channel.close being sent by the client. I'm
calling channel.close(None) on the txamqp channel object; is that the
wrong way to close a channel, or is there a problem with txamqp?

Thanks,
Tim

Tim,

Tim Cole wrote:
sending a channel.close method is definitely the correct way to close a
channel, but I do not know how that is exposed in the txamqp API.


Matthias.

It's kind of weird. As it turns out, txamqp exposes two methods on
channel objects, one which sends channel.close to the server, and one
which marks the channel as closed locally. To properly close a channel,
you end up having to call both individually.

Tim,

Tim Cole wrote:
I suggest you report that to the txamqp authors.


Regards,

Matthias.

So the problem turned out to be that txamqp's channel.close doesn't do
anything (as far as the sever is concerned). I have to do this instead:

d = channel.channel_close()
d.addCallback(channel.close)

Once I'm actually sending channel.close, it works fine. Eh well.