Hi Alexandr, ignite stop is not actual node failure in this case. isn't it ? how node singleton helps in this case ? Am i missing anything?
is there any way to intercept cache start and stop ? Thanks. On 16 December 2016 at 15:51, Alexandr Kuramshin <ein.nsk...@gmail.com> wrote: > Hi Anil, > > Right, you get stopping the node by the cause of segmentation. > > Call chain: > > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager. > DiscoveryWorker#onSegmentation > org.apache.ignite.internal.managers.discovery. > GridDiscoveryManager#stopNode > org.apache.ignite.Ignition#stop(java.lang.String, boolean) > > You could change IgniteConfiguration.setSegmentationPolicy() > to SegmentationPolicy.NOOP, so the node will not be stopped upon > segmentation (the default value is STOP). > > But the better way is to deploy the kafka streamer as a node singleton > [1], and implement it as a service, which could be automatically stopped > right before node do. > > [1] http://apacheignite.gridgain.org/docs/cluster-singletons > > > 2016-12-16 13:29 GMT+07:00 Anil <anilk...@gmail.com>: > >> Hi Anton and Alexandr, >> >> I thought vertx is invoking IgniteClusterManager#leave because of network >> segmentation. so I created wrapper to IgniteClusterManager and added logs >> before invoking leave(). I did not see any log of wrapper. So ignite is not >> closed from the IgniteClusterManager#leave >> >> Looks like ignite is stopped from some where else because of network >> segmentation? can you help me in understanding this. is there any to >> intercept behavior ? >> >> In my scenario, i am starting kafka streamer when ignite is up and need >> to stop the kafka streamer before closing the ignite due to any problem. >> otherwise, it would lead to data problem. and i am using vertx-ignite. >> >> please share if there are other cluster manager better than vertx ? >> >> Thanks for you help. >> >> >> - Anil >> >> > > > -- > Thanks, > Alexandr Kuramshin >