ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: Ignoring a node as a Service Grid deployment candidate
Date Mon, 07 Dec 2015 11:04:57 GMT

Agree that your solution sounds better. Created a ticket

Is there anyone in the community who can pick it up and fix the issue 
during the nearest month?


On 12/7/2015 8:08 AM, Dmitriy Setrakyan wrote:
> I don’t think that using Class definition to check if the node is part of
> service grid deployment is wrong. We should use the String class name
> instead. If we take this approach, will this fix the current class
> deployment which requires class definition on all the nodes?
> On Sun, Dec 6, 2015 at 6:26 PM, Roman Shtykh <rshtykh@yahoo.com.invalid>
> wrote:
>> Denis,
>> What will happen if node B becomes a deployment target due to topology
>> changes?
>> Thanks,
>> Roman
>> On Sunday, December 6, 2015 5:17 PM, Denis Magda <dmagda@gridgain.com>
>> wrote:
>> Igniters,
>> Presently every node that is a part of a cluster listens for Service
>> Grid assignment changes in order to find out whether a service has to be
>> deployed on it or not.
>> However, there is a possible case when a node is not considered to be a
>> target for service A at all during its lifetime. But the node has to
>> have a class definition of service A in its classpath in any case just
>> to check whether it's a target one or not.
>> In big cluster with many unrelated clients this can be an annoying thing
>> to take care of.
>> My understanding is that it makes sense to implement "all or nothing"
>> like approach for Service Grid cause it's the most easiest and
>> straightforward.
>> If a service is considered to be deployed on node A at some point of
>> time then node A has to have  class definitions of all the services in
>> its classpath.
>> On the other hand if node B is not considered to be a deployment target
>> for any service then it will be excluded from services deployment
>> related logic. We can add a special parameter to IgniteConfiguration to
>> address this.
>> What do you think on this approach? If we want to support more flexible
>> configurations lets go ahead and discuss them here.
>> --
>> Denis

View raw message