[rabbitmq-discuss] Return message? [Was: Re: Sample code for python?]
Allen Fowler
allen.fowler at yahoo.com
Mon Jul 6 16:54:15 BST 2009
> > In our case, the back-end machines will be .net or possibly Java. The front
> end web-UI will be python. (Likely TurboGears 2)
> >
> > As it stands now, the front end machines will be calling specific functions on
> the back-end boxes via a basic HTTP/XML API. For instance: "Place order for
> customer X"
> >
> > The back-end machines do whatever processing they need and reply with a result
> code. (Success, No Stock Left, System Busy, etc.)
> >
> > My idea was to use RabbitMQ for the request transport instread of HTTP. Is
> this a resonaable idea? Can/Should RabbitMQ be used in this sort of environment?
>
>
> In this case I have been writing the tool that you might need:
>
> http://bitbucket.org/adroll/quebert/overview/
>
> This is also written in Python but doesn't require Python anywhere else
> and deployment is easy.
>
> Most of the things I wrote in an old email to this list are still true:
> http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-June/004273.html
>
> Although the API changed a bit for the better.
>
> Essentially just using a mediator like this:
> http://bitbucket.org/adroll/quebert/src/tip/examples/med.py
>
> and starting it using (just one example):
> twistd --pidfile=/var/run/quebert.pid --logfile=/var/log/quebert.log quebert
> --config=med.main --with_syslog_prefix=quebert
> Would give you a system that for any message that gets in routes it to any
> available HTTP server that knows how to process it (and you can do this
> through a load balancer or directly sending the message).
>
> The actual example code can be used as a configuration file without
> changing it.
>
> You can then easily add more features through hooks or on the point
> of execution. I've essentially designed the system to answer your very
> same concerns :).
>
I am not at all familiar with the twisted system, but does this mean that RabbitMQ/AMQP does not, on it's own, provide any method for a message sender to ascertain the success or failure of a task embodied by a message?
That is to say: The backed system (job receiver) has no way of signaling to the front-end (job-sender) any details about the job the front-end is waiting on?
Is this true?
More information about the rabbitmq-discuss
mailing list