thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Haggerty <mumb...@gmail.com>
Subject Re: Using thrift with a message broker. Why?
Date Thu, 23 Jan 2014 23:06:54 GMT
I'm doing this at the moment because it's a better way to do long-running
async tasks (i.e. using thrift like celery, but never any return values).
This ends up being more useful than oneway, because if you use oneway you
don't ack (and there's no simple way to retry if it fails). Oneway also
ends up 'using up' a process if you're running a Python process pool style
server, whereas having consumers allows you to constrain how many processes
are soaked up by the long running function.

At least, it makes sense to me. Do you have links to other people
describing their use of AMQP?


On Fri, Jan 24, 2014 at 5:28 AM, Software Dev <static.void.dev@gmail.com>wrote:

> I've come across some examples of AMQP broker sitting between a client and
> service (Thrift). Can someone explain the benefits of this approach as
> opposed to just having the client speak directly to the service via the one
> of the native thrift transports?
>
> There are two reasons I can think of:
>
> 1) Loadbalancing. If we have multiple services as a consumer for a topic,
> we essentialy get loadbalancing for free.
>
> 2) No need to configure the service endpoints up front. We only need to
> write to the broker and not care about which machine, ip, etc can handle
> the request.
>
> Neither of which do I find as a compelling reason to add a broker. In use
> case 1 we can simply load balance via hardware or HAProxy. Use case two, if
> needed, be fixed with some distributed configuration management software
> (Zookeeper) where automatic detection is possible.
>
> Can someone please chime in with any input. Thanks
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message