Hi

Here my scenario:
In a pub/consumer situation a consumer creates a queue and binds this queue to a direct exchange with auto-delete flag set to True.
Then start listening to that queue for messages, we have got a timeout and when the timeout expires the consumer stop listening to and delete itself, as results the exchange is correctly deleted.
The publisher before publish a message try to create the exchange.

In this process can happen that the publisher try to publish a message on the exchange after it has been deleted by the consumer, as result I have got some direct exchange on Rabbitmq without a bind, and those exchanges will remain alive forever, I will refer to them as zombie
My questions are:

- Can you confirm that the publisher after publishing the message close the connection with Rabbitmq?

- What are risks to have a lot of those zombie exchanges ?

- There is a way to close zombie exchanges?

To solve the problem I am thinking to publish messages with mandatory flag set and to manage the Basic.return to close the exchange, is it a correct design?

Thanks
--
Andrea Rosa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20111205/7cc21a19/attachment.htm>

Search Discussions

  • Simon MacMullen at Dec 5, 2011 at 11:26 am

    On 05/12/11 09:57, Rosa, Andrea wrote:
    My questions are:

    -Can you confirm that the publisher after publishing the message close
    the connection with Rabbitmq?
    Well, that's up to the publisher. I would assume you would close the
    connection.
    -What are risks to have a lot of those zombie exchanges ?
    Well, they make your Mnesia database larger than it needs to be, and
    make the output of rabbitmqctl and mgmt unwieldy.
    -There is a way to close zombie exchanges?
    You could iterate through them in mgmt.
    To solve the problem I am thinking to publish messages with mandatory
    flag set and to manage the Basic.return to close the exchange, is it a
    correct design?
    Umm, you could I suppose. I would take a step back though - why are you
    creating short-lived direct exchanges all the time? What are you trying
    to do that you couldn't do with a single exchange, or with the default
    exchange?

    Cheers, Simon

    --
    Simon MacMullen
    RabbitMQ, VMware
  • Rosa, Andrea at Dec 5, 2011 at 12:04 pm
    Hi Simon

    Well, they make your Mnesia database larger than it needs to be, and
    make the output of rabbitmqctl and mgmt unwieldy.
    Ok, thanks
    -There is a way to close zombie exchanges?
    You could iterate through them in mgmt.
    Ok
    To solve the problem I am thinking to publish messages with mandatory
    flag set and to manage the Basic.return to close the exchange, is it a
    correct design?
    Umm, you could I suppose. I would take a step back though - why are you
    creating short-lived direct exchanges all the time? What are you trying
    to do that you couldn't do with a single exchange, or with the default
    exchange?
    Good question, I am implementing a RPC call so the server A ask for a remote call to server B, the server A declare the queue (temp_queueA) bind it to the direct exchange and wait for reply from server B.
    Server A send the request, server B gets and execute the request and sends back results using the exchange bound to the temp_queueA queue.

    Cheers
    --
    Andrea
  • Simon MacMullen at Dec 5, 2011 at 12:20 pm

    On 05/12/11 12:04, Rosa, Andrea wrote:
    Good question, I am implementing a RPC call so the server A ask for a
    remote call to server B, the server A declare the queue (temp_queueA)
    bind it to the direct exchange and wait for reply from server B.
    Server A send the request, server B gets and execute the request and
    sends back results using the exchange bound to the temp_queueA
    queue.
    So why not have server A declare temp_queueA, have it send that queue's
    name in the reply-to header, then have server B publish the message to
    temp_queueA via the default exchange? That's the usual pattern, it's
    quite a bit simpler, and I don't see what lots of extra exchanges is
    buying you.

    Cheers, Simon

    --
    Simon MacMullen
    RabbitMQ, VMware
  • Rosa, Andrea at Dec 5, 2011 at 1:45 pm
    Hi Simon,
    So why not have server A declare temp_queueA, have it send that queue's
    name in the reply-to header, then have server B publish the message to
    temp_queueA via the default exchange? That's the usual pattern, it's
    quite a bit simpler, and I don't see what lots of extra exchanges is
    buying you.
    Unfortunately I didn't participate to the original design of the system so I don't know which is the underlying idea.
    We can have a lot of temporary queues (like temp_queueA) and a lot of messages at the same time to have a single exchange (the default one) to deliver those messages could not be a bottleneck ?
    So maybe the original idea was to design the RPC using separate exchanges for having more scalability?
    I don't know it's just speculation.

    Cheers
    --
    Andrea
  • Simon MacMullen at Dec 5, 2011 at 1:48 pm

    On 05/12/11 13:45, Rosa, Andrea wrote:
    Unfortunately I didn't participate to the original design of the
    system so I don't know which is the underlying idea. We can have a
    lot of temporary queues (like temp_queueA) and a lot of messages at
    the same time to have a single exchange (the default one) to deliver
    those messages could not be a bottleneck ? So maybe the original idea
    was to design the RPC using separate exchanges for having more
    scalability? I don't know it's just speculation.
    It's possible that's what somebody thought :) But the built-in exchange
    types at least are just routing logic which is executed in the channel,
    there's no process there to be a bottleneck.

    Cheers, Simon
    --
    Simon MacMullen
    RabbitMQ, VMware
  • Rosa, Andrea at Dec 5, 2011 at 1:55 pm
    Thanks Simon,

    I found this topic really useful for me!
    --
    Andrea Rosa
    -----Original Message-----
    From: Simon MacMullen [mailto:simon at rabbitmq.com]
    Sent: 05 December 2011 13:49
    To: Rosa, Andrea
    Cc: rabbitmq-discuss at lists.rabbitmq.com
    Subject: Re: [rabbitmq-discuss] Zombie direct exchanges
    On 05/12/11 13:45, Rosa, Andrea wrote:
    Unfortunately I didn't participate to the original design of the
    system so I don't know which is the underlying idea. We can have a
    lot of temporary queues (like temp_queueA) and a lot of messages at
    the same time to have a single exchange (the default one) to deliver
    those messages could not be a bottleneck ? So maybe the original idea
    was to design the RPC using separate exchanges for having more
    scalability? I don't know it's just speculation.
    It's possible that's what somebody thought :) But the built-in exchange
    types at least are just routing logic which is executed in the channel,
    there's no process there to be a bottleneck.

    Cheers, Simon
    --
    Simon MacMullen
    RabbitMQ, VMware

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedDec 5, '11 at 9:57a
activeDec 5, '11 at 1:55p
posts7
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Rosa, Andrea: 4 posts Simon MacMullen: 3 posts

People

Translate

site design / logo © 2022 Grokbase