[rabbitmq-discuss] Flow Control

[Brian Sullivan]

Just one last followup on this, to make sure we're on the same page -

On Oct 22, 2008, at 8:49 AM, Ben Hood wrote:

> Brian,
>
> On Wed, Oct 22, 2008 at 4:39 PM, Brian Sullivan <bsullivan at lindenlab.com 
> > wrote:
>> What we have is a simple log file that we are then tailing and  
>> converting
>> into messages - this allows us to be logging in a simple way, using  
>> our
>> existing code, then we can attach a reader to funnel these messages  
>> into a
>> more flexible messaging system like RabbitMQ.  There we subscribe  
>> across the
>> event types (topics) and consume in various ways.  The log file is  
>> both a
>> reliable "fire and forget", as well as a common format to be  
>> consumed by
>> other processes if we needed.
>
> OK, I see. It has just occurred to me that you were using the Java
> client to accomplish this task. Just FTR I wanted to point out the
> existence of the Ruby (http://github.com/tmm1/amqp/tree/master) and
> Python (http://barryp.org/software/py-amqplib/) clients which are
> slightly more amenable to scripting that the Java library is.
>

Actually, we are going to use the Python library on the log parsing  
and publication side.  :)  The Java client is used on the consuming end.

>> So while it might be a bottleneck to mix all the messages together,  
>> it's an
>> acceptable one from our standpoint.  Let me know if I am still  
>> unclear, or
>> if you see something wrong with this approach.
>
> No that seems reasonable from the perspective that a catch all binding
> key is simpler to maintain that requiring knowledge of the entirety of
> all possible routing keys.
>

Just to be clear, the "catch all" part is the logging file.  When we  
parse the file and convert into messages to send to RabbitMQ, that's  
when we assign the various topic keys and allow it to do the routing.   
Each logging application is free to log whatever "key" it wants, then  
we can just set up something to pick it up on the consuming end when  
we're ready.

Thanks again,
Brian