[cluster] NotInfluenceReceiveTimeout in the Cluster ?

[otherview]

Hi !

Wondering if there's a way to implement a message that doesn't influence the grain timeout ?

Similar to NotInfluenceReceiveTimeout?

[potterdai]

@otherview Hi, thank you for asking! = ) I think you should just add NotInfluenceReceiveTimeout function to that message type, and should be OK. Since NotInfluenceReceiveTimeout is an interface, as long as your object matched that interface requirement, the message won’t affect timeout.

[otherview]

hmm.. to be honest I thought it wouldn't work and didn't try it !

Let me give it a go tomorrow and I'll post some results!

Thanks @PotterDai !

[otherview]

Was looking more into this.

The magic happens here: https://github.com/AsynkronIT/protoactor-go/blob/f81631684a62bfb0a9f3bf4170f4802d43174501/actor/actor_context.go#L420-L428

And it works fine for actors because we usually define the messages that we're passing around.

However in the cluster, we gRPC the message into a structure https://github.com/AsynkronIT/protoactor-go/blob/3a8d8611c9ecd2ed98b696b18b311185aff079ac/cluster/protos.proto#L14-L17

All the messages we pass along in the cluster will have that type. Maybe if we add something to the cluster.GrainRequest and check it in the _, influenceTimeout = md.(NotInfluenceReceiveTimeout)

That would work ?

[potterdai]

@otherview Hmm, I think you are right! Sorry that I mislead you in previous post! This feature is not supported in Cluster it seems. This is going to be tricky since adding only this parameter to GrainRequest seems to be a bit overwhelming...

[potterdai]

@otherview hmmm this is going to need some change. For now I came to the same path like you

message GrainRequest {
    int32 request_type = 1;
    int32 method_index = 2;
    bytes message_data = 3;
}

And add

func (*GrainRequest) NotInfluenceReceiveTimeout() bool {
    //will return true/false according to `request_type` 
}