Open Stack

"Eric Windisch" <eric at cloudscaling.com> said:

>> an rpc implementation that writes to disk and returns,
> 
> A what? I'm not sure what problem you're looking to solve here or what you think
> the RPC mechanism should do. Perhaps you're speaking of a Kombu or AMQP specific
> improvement?
> 
> There is no absolute need for persistence or durability in RPC. I've done quite a
> bit of analysis of this requirement and it simply isn't necessary. There is some
> need in AMQP for this due to implementation-specific issues, but not necessarily
> unsolvable. However, these problems simply do not exist for all RPC
> implementations...

This was a side issue and I probably should have left it out of my email. I
wasn't angling for persistence at all here.

Rather I was thinking that I sometimes see rpc casts taking 10-20 ms in
nova-api, and I wonder if we could pare that down without harming
reliability by writing casts to a local resource and streaming them over
the network in the background. I'm guessing if that local resource is disk
with fsyncs between each write, there would likely be a performance
degradation, so I'm not advocating that. But without fsyncs seemed like it
might be okay. Maybe this is just silly and you're about to tell me how it's
all a bad idea anyway :-)