Open Stack

This is what cells does, and I was planning on porting this to openstack-common for general RPC stuff, too.. so this is great.  However, I'd like to see the # of greenthreads for receiving responses be configurable…. definitely not locked to 1.

Might be a big enough change to how rpc.calls work to warrant a blueprint.

- Chris

On Nov 26, 2012, at 7:35 AM, Ray Pekowski <pekowski at gmail.com> wrote:

> I have a working prototype for replacing the dynamically created response queues/exchanges with a single queue per caller process.  It does fix the scaling problem in a non-mirroring RabbitMQ clustered environment.  It uses a single thread for receiving responses (consume_in_thread()) and a "call_waiting" dictionary as Vish suggested for correlating the message IDs with the waiting greanthread.  I need to do some more testing and cleanup, but I would like to know what the process to use for delivering this patch.  Should I report it as a (performance) bug?  Or should I open a blueprint?
> 
> Thanks,
> Ray
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev