Chris,

If it's exactly the thing that you want to achieve, you can start Ignite
twice. First time - to get contents of the "admin cache", and second time,
after all initialization is finished - to accept compute jobs.
To avoid compute jobs from being executed by the first node, you can run
them (jobs), using a cluster group filter. Something like this:

IgniteCompute compute = ignite.compute(
    ignite.cluster().forAttribute("ROLE", "worker"));

And the second node should be started with corresponding user attributes
configured. You can find here more about cluster groups and node
attributes:
https://apacheignite.readme.io/v2.3/docs/cluster-groups#section-cluster-groups-with-node-attributes

But this solution looks clumsy, I think. IMO, It's better to add some
synchronization to the beginning of your jobs. So, if a job comes to a
node, that haven't initialized yet, it will just wait until the
initialization is finished.
But if initialization is too long, and you think, that it will affect
latency too much, you can go with the first option.

Denis

вт, 21 нояб. 2017 г. в 0:06, Chris Berry <chriswbe...@gmail.com>:

> Hi Ilya,
>
> I think you are missing the point. It is a chicken-and-egg problem.
>
> I need to start Ignite so that I can do various things – like use some
> various “admin caches” to look up things, etc – BEFORE I can accept real
> load.
>
> But the way it stands today, Ignite _assumes_ that if it is started, then
> it
> must also be ready to participate in the ComputeGrid.
> That may be true for some, or even most, use cases, but it will NOT be true
> for all.
> These are separate lifecycle events.
> In my case, Ignite starts slamming the Node with load before it is fully
> initialized and ready for real load.
>
> Thus, I’ve had to reject all ComputeJobs in my implementation (in
> ComputeJob::execute()), and force them to be retried in
> ComputeTask:::result() (returning FAILOVER).
> This works, of course.
> But is pretty silly. And hurts performance badly during the transition
> period.
>
> What is needed is a simple gate. E.g “acceptComputeJobs”
> It could default to “true” at start-up.
> But, for those that need finer control of that lifecycle, it could allow
> you
> to start-up with acceptComputeJobs=false
> And, then flip it to true manually, when the Node is ready to participate.
>
> Make sense??
> Thanks,
> -- Chris
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Reply via email to