Reuben Bond

Thanks @jjmason - a rough PR largely as fuel for discussion (at least to begin with) would be great - so there's no need to make it clean/mergable quality

Apologies for the very long delay, @jjmason. I am in favor of the approach you've taken. One question is: if system performance degrades, would this change result in a spike...

I'd like to wait until our distributed testing infrastructure is back online before merging. In the meantime, I've left some comments. Thanks, as always

I agree, the hashing quality is a significant plus. I was looking for a reference I had from last time I looked into this. I think this is it: https://github.com/rurban/smhasher...

I think it's fine to use a mix of xxHash32 and xxHash64 depending on the case. We can use xxHash32 for the 32bit cases (`GetConsistentHashCode`, etc)

Great point, @amccool. Streams are conceptually separate from grain method calls, but they use calls under the hood. It seems to me that the grain extension interface which Orleans uses...

> I think a global configuration that specifies all calls to be long-running makes sense. Ultimately, that is setting the timeout for all grain method calls to be infinite. Infinite...

> Presumably you mean you can override that by providing your own `CancellationToken` and by decorating the method with an attribute that overrides the configured default/global timeout behaviour? I would...

What you're suggesting sounds fine to me, too.

@krasin-ga yes, it would. Which version are you running? I recall that we fixed an issue with StatelessWorker grains in heterogeneous clusters