Thank You. The issue is that I want to extend the notion of service failures beyond simple node failure/topology change scenarios.
I already have per Ignite service health check that runs custom health check on service and redeploys it if necessary obviously this is my custom implementation. So now I was dealing with the part of deploying service only on eligible nodes where eligibility is dynamic and can't be determined by for example static node attributes. Now I understand that nodeFilter is not actually a right approach as you explained and it was meant just to look to node static data like attributes and perform static filtering. I have another idea : To use ClusterGroup based deployment specifically predicate() method. So when I deploy a service it will run predicate() on nodes for example using the below Ignite closure and return subset of nodes based on my remote predicate. Will this work in your opinion ? Will Ignite run predicate() method of ClusterGroup when topology change for example ? Yes this is will be really helpful I have already created my own workaround around this issue but official support will be far better : https://issues.apache.org/jira/browse/IGNITE-8365 Thank You, Vladik On 5/28/18, 19:51, "aealexsandrov" <aealexsand...@gmail.com> wrote: Hi, Please take a look at my answers below: 1)Yes. Node filter should be run only on coordinator node after reassignment process. It could be executed several times and possible that Ignite instance can be uninjected. All this behavior should be documented as well as for me. 2) Node filter predicate should be stateless and should always return the same value for the same node. It means that using the compute task in return value as you did isn't correct. As I know there is no direct possibility to see that service deployed/undeployed now. In case if all nodes from nodeFiter were failed then Ignite will wait for them. I found next issue and possible that it could help with it when it will be ready - https://issues.apache.org/jira/browse/IGNITE-8365 You can try to handle the service nodes by their ids and in case if all of them are offline try to do something. BR, Andrei -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
