[rabbitmq-discuss] Publish to queue fails but publish to direct exchange works

[Raphael Simon]

Answers inline:

On Fri, Jun 18, 2010 at 12:07 AM, Matthias Radestock
<matthias at rabbitmq.com>wrote:

The reason we don't map the blank exchange name to something else is that
> RabbitMQ permits anything in the exchange name, so *** and --- actually are
> valid exchange names.


I understand but it seems to me that the pain it causes users in general is
greater than the remote chance somebody would have called its queue ---.
Alternatively you could wrap queue names e.g. around brackets. You could
also use a divider ' | ' (which would also be an issue if somebody called
its queue ' | ' but again it seems to me that the benefits way outweigh the
drawbacks).

Are all AMQP interactions going through nanite? I can see there aren't any
> queue.unbind actions in that code base.


Our code is based on nanite although we have heavily customized it now.


> I suggest you upgrade. The queue and exchange code has changed quite a bit
> in the recent release. While I do not recall us spotting any problems in the
> previous version that would explain the behaviour you are seeing, it is
> nevertheless possible that there was a bug in the previous code which has
> been eradicated by other changes.
>
>
OK We will see about upgrading, this is not such a simple task now that the
system is on production.


> ok. If you *do* think of a use case for auto-delete exchanges, please let
> us know. The AMQP 0-9-1 spec actually removes that

feature, but we are having second thoughts on whether that was the right
> thing to do.


will do.


>  I recreated some bindings from within the broker (directly in mnesia) and
>> now things started working again. Is there a better way to re-create the
>> binding to the default exchange without having to re-create the queue?
>>
>
> You should be able to issue an appropriate queue.bind command. As I
> mentioned earlier, such explicit operations on the default exchange should
> imo not be permitted, but rabbit does and it's a grey area of the spec. So
> currently it should work, just don't write any code that depends on it.
>
>  I should probably mention that sending the following queue.bind packet
>> didn't seem to help (rabbitmqctl list_bindings still shows the
>> binding  missing).
>>
>> [:sending,
>>  #<AMQP::Protocol::Queue::Bind:0x9b26778
>>  @arguments=nil,
>>  @debug=1,
>>  @exchange=
>>   "nanite-rs-instance-fd0416fe31d7b019112c2c0adce9b4e4a261bab1-1094976",
>>  @nowait=true,
>>
>>  @queue="nanite-rs-instance-fd0416fe31d7b019112c2c0adce9b4e4a261bab1-1094976",
>>  @routing_key=nil,
>>  @ticket=1>]
>>
>>
> The exchange in the above should be blank.
>

Setting the exchange to blank here did not seem to do the right thing. The
binding that is missing is the one from the queue name to the routing key
with the same name.

Also a different issue: Using a blank string with rabbitmqctl
set_permissions has the same effect as using a wild card (.*). This seems a
little bit counter-intuitive (i.e. rabbitmqctl set_permissions user "" "' ""
has the same effect as rabbitmqctl set_permissions user ".*" ".*" ".*").

Finally a different question: is there a way to force a disconnect from a
client from the broker? we have code that will force the client to recreate
the binding and resubscribe if the connection gets broken and it would be
nice if we could trigger this manually.


>
> Regards,
>
> Matthias.
>

Thanks for the help!

--
Raphael.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20100618/25faeeb4/attachment.htm>