Hi, Regarding service redeployment on reactivation – that’s https://issues.apache.org/jira/browse/IGNITE-8205, already fixed in the master branch, will be in 2.6.
Regarding executing cancel() in the exchange thread – agree, that doesn’t seem right. I guess currently we just run init() and cancel() in whichever thread causes them to be called (I wonder if fix the for IGNITE-8205 causes init() to be executed in the exchange thread as well – needs to be checked). The deployment executor of the service processor seems to be a good fit. Perhaps the latter can be checked and fixed in the IEP-17 (https://cwiki.apache.org/confluence/display/IGNITE/IEP-17:+Oil+Change+in+Service+Grid). *Denis Mekhanikov*, could you please tell if execution of service methods in possibly inappropriate threads is on the radar of the IEP-17 already, or does it make sense to add a new issue in the list? Thanks, Stan From: npordash Sent: 27 апреля 2018 г. 3:05 To: user@ignite.apache.org Subject: Service isn't initialized on cluster re-activation Hi, I was doing some testing where I had some services deployed, then deactivated the cluster, then re-activated the cluster. I was expecting that the services would have their init and execute methods called again, but this did not happen. If I proceed to shutdown a node then the cancel method is called even though the service never went through proper initialization. I'm observing this behavior regardless if persistence is enabled or not; however, if persistence is enabled and I completely restart the cluster then all services are re-initialized as expected. This is on Ignite 2.4 and a quick reproducer is: I see the following output when run: In addition, you'll also notice that when the service is cancelled because of cluster deactivation that this occurs from the exchange thread which seems incredibly dangerous to me since it can cause the cluster to deadlock if you do anything in the cancel method that may block (f.e. any call that leads to GridClusterStateProcessor.publicApiActiveState(true)). I found IGNITE-8279 but upfront this appears to be a different issue, but not sure if it's related to what I'm observing as this use-case isn't using a client. -Nick -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/
