My understanding had been that if a consumer is canceled (and its
channel closed) without having acked delivered messages, then those
messages become available to later consumers on the same queue. That
doesn't actually appear to be happening, however.

I have a bit of code which is essentially doing:

==> basic.consume
<== basic.deliver
# transient application error happens
==> basic.cancel
==> channel.close

==> channel.open
==> basic.consume
# no message delivered

I would expect to get a basic.deliver with the same message as before,
since the message wasn't acked the first time. I'm not, though. Is
there more to it than this?

[Note that I am not using no_ack, and that the queue in question is
durable and not exclusive or autodeleted]

Thanks,
Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100615/d53d4615/attachment.pgp>

Search Discussions

  • Matthew Sackman at Jun 15, 2010 at 5:49 pm

    On Tue, Jun 15, 2010 at 01:23:42PM -0400, Tim Cole wrote:
    My understanding had been that if a consumer is canceled (and its
    channel closed) without having acked delivered messages, then those
    messages become available to later consumers on the same queue.
    You're understanding is correct - the key part is the channel being
    closed.
    That doesn't actually appear to be happening, however.
    I have a bit of code which is essentially doing:

    ==> basic.consume
    <== basic.deliver
    # transient application error happens
    ==> basic.cancel
    ==> channel.close

    ==> channel.open
    ==> basic.consume
    # no message delivered

    I would expect to get a basic.deliver with the same message as before,
    since the message wasn't acked the first time. I'm not, though. Is
    there more to it than this?
    Hmm. Can you isolate the code that is doing this - it really shouldn't
    be happening.

    Matthew
  • Matthew Sackman at Jun 15, 2010 at 5:51 pm

    On Tue, Jun 15, 2010 at 06:49:19PM +0100, Matthew Sackman wrote:
    On Tue, Jun 15, 2010 at 01:23:42PM -0400, Tim Cole wrote:
    My understanding had been that if a consumer is canceled (and its
    channel closed) without having acked delivered messages, then those
    messages become available to later consumers on the same queue.
    You're understanding is correct - the key part is the channel being
    closed.
    Apologies. I shall return to school now to be taught the difference
    between your and you're.

    Matthew
  • Matthias Radestock at Jun 15, 2010 at 6:01 pm
    Tim,
    On 15/06/10 18:49, Matthew Sackman wrote:
    On Tue, Jun 15, 2010 at 01:23:42PM -0400, Tim Cole wrote:
    I have a bit of code which is essentially doing:

    ==> basic.consume
    <== basic.deliver
    # transient application error happens
    ==> basic.cancel
    ==> channel.close

    ==> channel.open
    ==> basic.consume
    # no message delivered

    I would expect to get a basic.deliver with the same message as before,
    since the message wasn't acked the first time. I'm not, though. Is
    there more to it than this?
    Hmm. Can you isolate the code that is doing this - it really shouldn't
    be happening.
    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.
  • Tim Cole at Jun 15, 2010 at 6:39 pm

    On Tue, 2010-06-15 at 19:01 +0100, Matthias Radestock wrote:
    Hmm. Can you isolate the code that is doing this - it really shouldn't
    be happening.
    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.
    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
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: This is a digitally signed message part
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100615/5832cb4a/attachment-0001.pgp>
  • Matthias Radestock at Jun 15, 2010 at 7:22 pm
    Tim,

    Tim Cole wrote:
    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?
    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.
  • Tim Cole at Jun 17, 2010 at 9:47 pm

    On Tue, 2010-06-15 at 20:22 +0100, Matthias Radestock 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.
    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.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: This is a digitally signed message part
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100617/e34f6847/attachment.pgp>
  • Matthias Radestock at Jun 17, 2010 at 9:49 pm
    Tim,

    Tim Cole wrote:
    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.
    I suggest you report that to the txamqp authors.


    Regards,

    Matthias.
  • Tim Cole at Jun 15, 2010 at 7:36 pm
    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.
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 198 bytes
    Desc: This is a digitally signed message part
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100615/eeedd087/attachment.pgp>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedJun 15, '10 at 5:23p
activeJun 17, '10 at 9:49p
posts9
users3
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase