[rabbitmq-discuss] Net::AMQP Perl Client - Status?

Wed Jan 14 19:15:42 GMT 2009

Hi Tony,

Thanks again for your help; I think I understand more of the nuances
between STOMP-RabbitMQ now.  As a sanity check, could you confirm the
following findings:

1) Since RabbitMQ implements only v0.8 (0-8) of the AMQP spec, it does
not support the 'headers' exchange type (as defined in 0-10 spec).
Correct?
If this is correct, can anyone indicate when the 'headers' exchange
type will be (expected to be) introduced into a version of RabbitMQ?
(v1.6?)

2) Both (0-8) and (0-10) AMQP specifications talk about "message
priority" (i.e., message.delivery-priority).  Can you give me an
example of how you construct different priority messages via
Net::STOMP?  Do you just specify the "priority" header with an integer
value of 0,1,2,3,4,5,6,7,8, or 9?  Or, are message priorities not even
implemented in RabbitMQ v1.5?

Thanks again,
-- Darien

On Sun, Jan 11, 2009 at 5:38 PM, Tony Garnock-Jones <tonyg at lshift.net> wrote:
> Hi Darien,
>
> Exchanges have to be declared out-of-band ahead of time (though a clean
> approach to doing the declarations via STOMP would be a great contribution),
> but Queues are declared at the point of subscription.
>
>  1. A queue.declare is done as part of SUBSCRIBE. The boolean STOMP
>    headers "passive", "durable", "exclusive" and "auto-delete" are used
>    as part of the declaration. (They all default "false" except
>    "auto-delete", which defaults "true".)
>
>  2. If the "exchange" STOMP header is present, a queue.bind is done
>    (using also STOMP header "routing_key").
>
>  3. Finally, a basic.consume is done.
>
> So, to address your second question: it has actually declared and started
> consuming from the queue! So the waiting is expected behaviour.
>
> Regards,
>  Tony
>
> Darien Kindlund wrote:
>>
>> Hi Tony,
>>
>> Great!  That answers most of my questions.... Lastly, I assume you
>> still have to pre-declare all your exchanges and queues *outside* of
>> Net::Stomp (through some other AMQP interface) -- correct?  I got the
>> impression that if any of the exchanges or queues were torn down
>> between successive executions of a Net::Stomp client, that any
>> messages sent would be silently dropped.
>>
>> That leads me to another question -- apparently, when subscribing to a
>> non-existent queue, the Net::Stomp client does not kick back any type
>> of exception.  Instead, it appears to blindly sit and wait forever,
>> with no notification that the bind was unsuccessful.  I assume this is
>> a known limitation, right?
>>
>> Regards,
>> -- Darien
>>
>> On Sun, Jan 11, 2009 at 1:41 PM, Tony Garnock-Jones <tonyg at lshift.net>
>> wrote:
>>>
>>> Hi Darien,
>>>
>>> (CCs trimmed)
>>>
>>> Darien Kindlund wrote:
>>>>
>>>> Additionally, I was curious if the STOMP adapter provides a way for a
>>>> Net::Stomp perl client to connect to a different vhost (other than
>>>> '/').
>>>
>>> Yes: supply a custom header, "virtual-host", to the CONNECT command. I'm
>>> not
>>> 100% certain, but I suspect you can do this by
>>>
>>>  $stomp->connect({login=>'guest', passcode=>'guest',
>>>                  "virtual-host"=>'/my-virtual-host'})
>>>
>>> There are a couple of other extension headers available; I'm afraid I
>>> haven't gotten around to the dreaded documentation yet, so reading
>>> rabbit_stomp.erl is the only way to discover them. A quick grep provides:
>>>
>>>  CONNECT virtual-host
>>>  CONNECT realm
>>>  SEND exchange
>>>  SUBSCRIBE exchange
>>>  SUBSCRIBE routing_key
>>>  various message properties in SEND
>>>  queue and binding attributes in various methods
>>>   (X-, X-Q-, X-B- prefixes)
>>>
>>> Regards,
>>>  Tony
>>>
>