[rabbitmq-discuss] rabbitmq-shovel issues [for hyperthunk]

Fri May 31 20:42:48 BST 2013

Yes I did and reposted under a "new" thread (not used to mailing lists)
called [rabbitmq-discuss] Shovel authentication question (possible bug)

On 5/31/13 10:29 AM, "ext Tim Watson" <tim at rabbitmq.com> wrote:

>Hi John,
>
>Did you try Matthias' suggestions out? Are you still struggling with
>this? It'd be good to get you past these hurdles since I know you've been
>trying to get this to work for quite some time now.
>
>Cheers,
>Tim (aka hyperthunk)
>
>On 30 May 2013, at 21:58, Matthias Radestock wrote:
>
>> On 30/05/13 21:35, john.hayden at nokia.com wrote:
>>> I have 2 Rabbits running on 2 different ec2 instances in AWS
>>> Rabbit1 has had a Shovel plugin installed in order to send messages to
>>> Rabbit2
>>> These Rabbits are being used for a Sensu monitoring network
>>> The Sensu server is in the same region as Rabbit1
>>> When a message is sent by Sensu to Rabbit1 it fansout to all connected
>>> queues (maybe the wrong terminology here), including one called
>>>us-west-2
>>> The Shovel is supposed to pick up messages from us-west-2 and forward
>>>it
>>> to Rabbit2
>>> Later on I will add other queues to forward to other Rabbits
>>> 
>>> As I try this setup, I seem to timeout on a connection and I don't
>>>know why.
>>> 
>>> Here is a gist of what is going on:
>>>https://gist.github.com/jhhayden/5679708
>> 
>> Have you checked the obvious, i.e. whether the Rabbit1 machine can
>>connect to both endpoints? In particular, on Rabbit1 run
>> 
>> telnet 54.243.157.166 5672
>> 
>> and then type AMQPxx<return>
>> 
>> This should reply with 'AMQP<somestuff>' and close the connection.
>> 
>> Then try the same for the other connection, i.e. 'telnet 54.245.126.50
>>5672'.
>> 
>> Also, it's worth checking the rabbit logs on both brokers for
>>connection attempts and errors.
>> 
>> 
>> A few other points...
>> 
>> - you say that the shovel is running on rabbit1 and shovelling to
>>rabbit2. That means it would be better to use a direct connection to
>>rabbit1 instead of a network connection. From
>>http://www.rabbitmq.com/shovel.html#configuration "If the [URI] host is
>>omitted [...] the shovel uses a direct connection to the broker in which
>>it is running. This avoids using the network stack.". In addition to
>>better performance, direct connections are not affected by network
>>issues, which should make it easier to debug the problem you are seeing.
>> 
>> - there's no need to specify the port 5672 in the URI since that is the
>>default
>> 
>> Regards,
>> 
>> Matthias.
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>_______________________________________________
>rabbitmq-discuss mailing list
>rabbitmq-discuss at lists.rabbitmq.com
>https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss