Continuation of this thread is here:
http://apache-ignite-users.70518.x6.nabble.com/ignite-compute-ClusterGroup-is-broken-td18655.html
пн, 27 нояб. 2017 г. в 3:30, Chris Berry :
> Affinity is not affected by IgniteCompute. My mistake.
> I get a hold of an IgniteCompute _before_ the Affi
Affinity is not affected by IgniteCompute. My mistake.
I get a hold of an IgniteCompute _before_ the Affinity is applied
>> I'm not sure, what you are trying to say.
I mean is -- I do this;
ignite.compute().withTimeout(timeout).execute(computeTask, request);
Up-front. Before I exe
> Affinity is not affected by IgniteCompute. My mistake.
> I get a hold of an IgniteCompute _before_ the Affinity is applied
I'm not sure, what you are trying to say.
Correct me, if I'm wrong, but you are trying to choose a node to run a
compute task on, depending on where a needed key is stored (
Hi Denis,
You are correct. Thank you!
Affinity is not affected by IgniteCompute. My mistake.
I get a hold of an IgniteCompute _before_ the Affinity is applied.
So. It seems that a “dynamic cluster group based on a predicate” will work
beautifully!!
I can simply add my gating function there.
I kn
> Would you stop Ignite & start it again??
Yes, I meant that. You can't tell Ignite not to take compute tasks, you can
only configure compute tasks not to be executed on certain nodes. So, the
first run will be to read configuration, the second one - to execute tasks
and do everything else. To avoi
Hi Denis,
Thank you very much for responding.
I’m unclear what you meant by “start Ignite twice”??
I don’t really understand how that scenario would work.
Would you stop Ignite & start it again??
And, if so, wouldn’t that cause a whole new “rebalancing” to occur??
Is there a “soft restart” that I
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 (j
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,
Hello Chris?
Are you using ignite-spring bindings? There's a problem with initialization
lifecycle that will be fixed in the next release:
https://issues.apache.org/jira/browse/IGNITE-6555
If that is the case, as a workaround you can put Ignite in a dedicated
context and only start it at the last
Hi Chris!
Can you just start Ignite after you finished all initialization that is
needed by compute jobs?
Denis
чт, 16 нояб. 2017 г. в 21:25, Chris Berry :
> No. There are things in the general application that are not yet
> initialized.
> It is essentially a chicken-and-egg problem.
> I need t
No. There are things in the general application that are not yet initialized.
It is essentially a chicken-and-egg problem.
I need to start Ignite, and do various other things before I am ready to
take load.
But as soon as Ignite is started -- it starts to take ComputeJobs.
We really need a way to
Chris,
Sorry, I still don't understand. What are the things that need to happen
exactly? Is there anything on Ignite level that is not initialized when job
arrives for execution?
-Val
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
Hi Val,
"Prematurely" in this case is a Node not fully initialized.
In a nutshell, Ignite is started, enters the "discovery set", but further
things must happen for it to be ready to do computation (take real load).
When the Grid is initially started, this is pretty easy to control -- we can
gate
Hi Chris,
Can you define "prematurely"? What exactly is required for a node to be
ready to execute jobs? From Ignite perspective, it is ready as long as it's
in topology on discovery level, and that's when it starts receiving
requests.
BTW, with AdaptiveLoadBalancingSpi you can implement custom
A
Hmmm, the raw code does not appear to be visible.
Reposting
public Map map(List
subgrid, @Nullable TRequest request) throws IgniteException {
Map jobMap = new HashMap<>();
List cacheKeys = getIgniteAffinityCacheKeys(request);
Map> nodeToKeysMap =
ignite.
I figure I should probably add my map() method.
I think this is all further complicated because we rely heavily on Affinity.
I was thinking that could maybe use the AdaptiveLoadBalancingSpi
But I see no way to add my own metrics to ClusterMetrics
Plus, I do not see how this would work with
af
Hi,
We are using Ignite’s Compute Grid. And mostly, it is working beautifully.
But there is one glitch I need to work around.
AWS, Nodes come and go.
And when a new Node joins the existing Grid, it is given ComputeJobs before
it is actually ready to handle them.
In our infrastructure, a Node an
17 matches
Mail list logo
