"Eric Windisch" <e...@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 :-) _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
