[rabbitmq-discuss] Unexaplainable behaviour with shovel plugin.

[Laing, Michael]

I'm a little out of date on federation, but yes, since you configure by
providing 'upstreams' I think it is basically a pull, although there seem
to be agents on both ends, unlike the simple shovel.


On Tue, Mar 4, 2014 at 2:42 PM, Jason McIntosh <mcintoshj at gmail.com> wrote:

> Well, true shovels can push or pull.  One thing though is I don't think
> federation can do a push - or did I miss that?
>
> Jason
>
>
> On Tue, Mar 4, 2014 at 1:38 PM, Laing, Michael <michael.laing at nytimes.com>wrote:
>
>> Actually shovels can be configured to push or pull - we use them both
>> ways.
>>
>> Our proxies are passive (no shovels) with well-known addresses - we use
>> shovels to push and pull to them from both sides.
>>
>> Our retail layer autoscales but the wholesale layer has known addresses -
>> we run shovels in the retail instances, some pushing and some pulling.
>>
>> Soon we will be using serf gossiping for topology/address/role discovery
>> in nyt⨍aбrik, and the need for known addresses will diminish greatly.
>>
>> ml
>>
>>
>> On Tue, Mar 4, 2014 at 2:21 PM, Jason McIntosh <mcintoshj at gmail.com>wrote:
>>
>>> The big thing for us was it was a push vs. pull mechanism.  In a
>>> distributed system, where we have a lot of nodes talking to an enterprise,
>>> it's much more efficient to have the nodes shovel to the enterprise than to
>>> have to have the enterprise have to know about every server connected to
>>> it.
>>>
>>> Jason
>>>
>>>
>>> On Mon, Mar 3, 2014 at 6:26 AM, Simon MacMullen <simon at rabbitmq.com>wrote:
>>>
>>>> On 28/02/2014 6:14PM, Ben Hood wrote:
>>>>
>>>>> Using federation to implement an AMQP gateway seems like a common
>>>>> pattern. One wonders why it didn't go into the AMQP spec ....
>>>>>
>>>>
>>>> I dunno, I think federation is really quite specific (I don't think
>>>> there are any other brokers which do it in the same way as RabbitMQ) - I
>>>> can see the spec authors not wanting to predict how people will want to
>>>> federate.
>>>>
>>>>
>>>>  Initially I had thought that the 'new' federation replaced the 'old'
>>>>>> shovel,
>>>>>> but this is not true - each tool has its place although their
>>>>>> capabilities
>>>>>> overlap.
>>>>>>
>>>>>> With easier configuration in 3.3, the lowly shovel may get its due!
>>>>>>
>>>>>
>>>>> It's interesting to see that the shovel still lives on, despite it
>>>>> being quite an agricultural component.
>>>>>
>>>>
>>>> I think the concept ("I just want to move the damn messages!") makes a
>>>> lot of sense.
>>>>
>>>> If I were creating RabbitMQ from scratch, I might rename the shovel to
>>>> something like "point-to-point federation" to make it a bit clearer that it
>>>> complements federation rather than being replaced by it.
>>>>
>>>>
>>>> Cheers, Simon
>>>>
>>>> --
>>>> Simon MacMullen
>>>> RabbitMQ, Pivotal
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>
>>>
>>>
>>>
>>> --
>>> Jason McIntosh
>>> https://github.com/jasonmcintosh/
>>> 573-424-7612
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Jason McIntosh
> https://github.com/jasonmcintosh/
> 573-424-7612
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20140304/dec8fd77/attachment.html>