ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Daradur <daradu...@gmail.com>
Subject Re: Service grid redesign
Date Wed, 25 Jul 2018 18:58:27 GMT
Denis, long service initialization isn't a big problem for us.

The problem is hung initialization, that means the service deployment
will never complete.
On Wed, Jul 25, 2018 at 8:08 PM Denis Mekhanikov <dmekhanikov@gmail.com> wrote:
>
> Vyacheslav,
>
> I think, that this timeout shouldn't be mandatory, and it should be
> disabled by default.
> We should be ready for long service initialization. So, it shouldn't be
> done in any crucial threads like discovery or exchange.
>
> Denis
>
> ср, 25 июл. 2018 г. в 15:59, Vyacheslav Daradur <daradurvs@gmail.com>:
>
> > FYI, I've filled the tickets:
> > https://issues.apache.org/jira/browse/IGNITE-9075
> > https://issues.apache.org/jira/browse/IGNITE-9076
> > On Wed, Jul 25, 2018 at 12:54 PM Vyacheslav Daradur <daradurvs@gmail.com>
> > wrote:
> > >
> > > > I think such timeout should be determined on per-service level. Can we
> > make
> > > > it part of the service configuration, or pass it into deploy method?
> > >
> > > Agree, per ServiceConfiguration level is more flexible solution.
> > >
> > > > This is a great question. Will the service be able to continue
> > operating
> > > > after the cache is destroyed? If not, I would undeploy it
> > automatically. If
> > > > yes, I would keep it. Please make sure that you are carefully printing
> > out
> > > > informative logs in either case, to make sure that there is no magic
> > > > happening that is hidden from users.
> > >
> > > A service will be able to work till topology's change after that we
> > > have to recalculate assignments and at this moment we won't determine
> > > suitable nodes.
> > >
> > > I will fill new tickets to work on these questions and to implement
> > > solutions in the second iteration if nobody doesn't mind.
> > > Anyway, it will have been done to a release.
> > > On Wed, Jul 25, 2018 at 12:08 PM Dmitriy Setrakyan
> > > <dsetrakyan@apache.org> wrote:
> > > >
> > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > >
> > > > > Igniters, please help me to clarify the following questions:
> > > > >
> > > > > 1). According to the issue [1] we should propagate services
> > deployment
> > > > > results to an initiator, that means we should wait for wor
> > > > > Service#init method completion.
> > > > > How should we handle Service#init method hangup?
> > > > > I propose to introduce some kind of
> > > > > IgniteSystemProperties#IGNITE_SERVICE_INIT_TIMEOUT to interrupt long
> > > > > initialization.
> > > > >
> > > >
> > > > I think such timeout should be determined on per-service level. Can we
> > make
> > > > it part of the service configuration, or pass it into deploy method?
> > > >
> > > >
> > > > > 2) Should we automatically undeploy services, which had been deployed
> > > > > using #deployKeyAffinitySingleton, on destroying of related
> > IgniteCache?
> > > > >
> > > > >
> > > > This is a great question. Will the service be able to continue
> > operating
> > > > after the cache is destroyed? If not, I would undeploy it
> > automatically. If
> > > > yes, I would keep it. Please make sure that you are carefully printing
> > out
> > > > informative logs in either case, to make sure that there is no magic
> > > > happening that is hidden from users.
> > > >
> > > >
> > > > > Thoughts?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3392
> > > > > On Tue, Jul 24, 2018 at 3:01 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Got it.
> > > > > >
> > > > > > Yes, we will preserve this behavior.
> > > > > >
> > > > > > Thanks!
> > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > By default the client nodes should be excluded form service
> > > > > deployment. The
> > > > > > > only way to include clients is to explicitly specify them
> > through node
> > > > > > > filter. This is how services are deployed today and we
should
> > preserve
> > > > > this
> > > > > > > behavior.
> > > > > > >
> > > > > > > D.
> > > > > > >
> > > > > > > On Tue, Jul 24, 2018 at 11:20 AM, Denis Mekhanikov <
> > > > > dmekhanikov@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Maybe let's keep the functionality the way it is,
since it
> > doesn't
> > > > > > > > interfere with the IEP?
> > > > > > > >
> > > > > > > > But I think, it's worth mentioning as a warning in
log, that a
> > > > > service is
> > > > > > > > deployed on a client node.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > вт, 24 июл. 2018 г. в 12:44, Vyacheslav Daradur
<
> > daradurvs@gmail.com
> > > > > >:
> > > > > > > >
> > > > > > > > > No, it's doesn't complicate implementation on
the current
> > stage.
> > > > > > > > >
> > > > > > > > > But we will have to change assignment function
to forbid
> > client
> > > > > nodes
> > > > > > > > > even if configuration's node filter resolves
them it can be
> > not
> > > > > > > > > transparent for the end user.
> > > > > > > > >
> > > > > > > > > I think the only use case to have such behavior
is: hosting
> > of not
> > > > > > > > > collocated services on data free nodes with access
to
> > IgniteCaches
> > > > > on
> > > > > > > > > remote nodes in the same cluster.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Jul 24, 2018 at 12:10 PM Denis Mekhanikov
<
> > > > > dmekhanikov@gmail.com
> > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > I don't think, that client nodes, that host
services make
> > much
> > > > > sense.
> > > > > > > > > > May we forbid it? Does anybody know, when
it may be useful?
> > > > > > > > > >
> > > > > > > > > > Vyacheslav, does it complicate the implementation
somehow?
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > вт, 24 июл. 2018 г. в 11:57, Vyacheslav
Daradur <
> > > > > daradurvs@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > Hi, Igniters!
> > > > > > > > > > >
> > > > > > > > > > > I am close to completing the main tasks
and I'm going to
> > > > > request a
> > > > > > > > > > > review in a couple weeks.
> > > > > > > > > > >
> > > > > > > > > > > I have a question about the new design:
> > > > > > > > > > >
> > > > > > > > > > > The current implementation of Service
Grid doesn't' take
> > into
> > > > > account
> > > > > > > > > > > Ignition#client(true).
> > > > > > > > > > > It means that *clients* nodes are able
to host services.
> > There
> > > > > are
> > > > > > > > > > > some tests that expect such behavior.
> > > > > > > > > > >
> > > > > > > > > > > Services assignments are managed by
a predicate only
> > > > > > > > > > > (ServiceConfiguration#setNodeFilter(IgnitePredicate<
> > > > > ClusterNode>).
> > > > > > > > > > >
> > > > > > > > > > > Should deployment on clients nodes
be forbidden or we
> > > > > shouldn't mix
> > > > > > > > > > > concepts for IgniteCache with Service
Grid?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Jun 20, 2018 at 1:46 AM Dmitriy
Setrakyan <
> > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM,
Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi Dmitriy,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Yes, the task [1] is planned
to be implemented once
> > the
> > > > > main
> > > > > > > > tasks
> > > > > > > > > > > > > will be completed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > https://issues.apache.org/jira/browse/IGNITE-8367
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Awesome! This is a huge addition
to the project.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Jun 19, 2018 at 10:06
PM Dmitriy Setrakyan
> > > > > > > > > > > > > <dsetrakyan@apache.org>
wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Vyacheslav,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > How about service redeployment
in case if user
> > wants to
> > > > > update
> > > > > > > > > the
> > > > > > > > > > > code?
> > > > > > > > > > > > > Is
> > > > > > > > > > > > > > this planned?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > D.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Mime
View raw message