[rabbitmq-discuss] Where too now?

[Tim Perrett]

Thanks for that Michael - most useful.

Based on some reading ive done elsewhere, the queues are created
programatically by the consumers? Would I be right in saying that each
application (consumer) has a single queue, and then if I want say,
granularity to session level in a web app, thats handled by the
consumer rather than creating shed loads of queues?

Cheers, Tim



On Wed, May 13, 2009 at 1:03 PM, Michael Arnoldus <chime at mu.dk> wrote:
> Senders shove messages into exchanges, bindings move them to zero or more
> queues. Clients take from the queues.
>
> Using the scenario you previouslf described we send each information type to
> a specific exchange of type fanout. The clinet has one or more queues bound
> to the exchanges it wants information from. Use one or more queues for each
> client depending on how tho client uses the info.
>
> Michael
>
> On May 13, 2009, at 13:39 , Tim Perrett wrote:
>
>> Hey Colin,
>>
>> Im using a scala abstraction that's part of the lift framework project
>> (which im a committer on). We have dispatcher and sender
>> implementations I do belive... right now im just trying to bridge the
>> knowledge gap and figure out what does what. The code is here:
>>
>> http://is.gd/zsjO
>>
>> The chap who wrote our implementation (Steve J @ twitter) is not
>> really active in the team anymore so im just trying to work through
>> what he's made and fill my knowledge gaps about rabbit mq as I go
>> along.
>>
>> Based on my vauge understand right now, the senders shove messages
>> into the ques and the dispatchers serve messages up to lisening
>> clients - applications in this case. Does that sound about right?
>>
>> Cheers, Tim
>>
>> On Wed, May 13, 2009 at 2:33 AM, Colin Z <theczintheroc2007 at gmail.com>
>> wrote:
>>>
>>> Depends on what languages you will use to interface with the Rabbit
>>> server/cluster.
>>>
>>> I found the C# client library very easy to use. The Erlang client library
>>> was a little bit tricker and I ran into some error-handling issues but I
>>> think these were fixed in more recent versions, I haven't checked.
>>>
>>> IMHO, the team has done an excellent job of making Rabbit as "fire and
>>> forget" as an Erlang app can be.
>>>
>>>
>>>
>>> On Tue, May 12, 2009 at 7:39 PM, Tim Perrett <tperrett at googlemail.com>
>>> wrote:
>>>>
>>>> Thanks Michael, thats good to hear.
>>>>
>>>> Any advice on the implementation? what to do and what to avoid?
>>>>
>>>> Cheers, Tim
>>>>
>>>> On Tue, May 12, 2009 at 7:50 PM, Michael Arnoldus <chime at mu.dk> wrote:
>>>>>
>>>>> Hi Tim,
>>>>>
>>>>> Sounds like a good plan. We're using AMQP for exactly the same purpose
>>>>> in
>>>>> the same way.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Arnoldus
>>>>>
>>>>>
>>>>> On May 12, 2009, at 19:10 , Tim Perrett wrote:
>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> This is my first post to this list - im afraid im a bit of a rabbitmq
>>>>>> n00bie! I've got everything setup and working and now looking to do
>>>>>> something good with it to understand how it all works for my use case.
>>>>>>
>>>>>> Essentially I have some backend tools that expose services with SOAP -
>>>>>> for which my app will repeatedly get data from - probably every 10
>>>>>> seconds, maybe less i've not decided yet. Anyway... said app gets said
>>>>>> data from those services. What I would then like it to do is notify
>>>>>> any other consumers (which will be other applications) that have opted
>>>>>> to subscribe to information / updates about that job via AMQP.
>>>>>> Consumers will also be able to hand messages to the central service
>>>>>> and effectively say "deal with this job and notify me about any
>>>>>> changes".
>>>>>>
>>>>>> Now then, excuse my complete ignorance, but its possible to build such
>>>>>> a workflow, right? Any pro's / con's in doing this? What would be the
>>>>>> optimal way to build such a system from a RabbitMQ POV?
>>>>>>
>>>>>> Just looking for a bit of a sounding board right now so any
>>>>>> information / feedback would be greatly appreciated.
>>>>>>
>>>>>> Cheers, Tim
>>>>>>
>>>>>> _______________________________________________
>>>>>> rabbitmq-discuss mailing list
>>>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> rabbitmq-discuss mailing list
>>>> rabbitmq-discuss at lists.rabbitmq.com
>>>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>>>
>>>
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>