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 <dmekhani...@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 <daradu...@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 <daradu...@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 > > > <dsetrak...@apache.org> wrote: > > > > > > > > On Tue, Jul 24, 2018 at 9:14 PM, Vyacheslav Daradur < > > daradu...@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 < > > daradu...@gmail.com> > > > > > wrote: > > > > > > > > > > > > Got it. > > > > > > > > > > > > Yes, we will preserve this behavior. > > > > > > > > > > > > Thanks! > > > > > > On Tue, Jul 24, 2018 at 2:20 PM Dmitriy Setrakyan < > > dsetrak...@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 < > > > > > dmekhani...@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 < > > daradu...@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 < > > > > > dmekhani...@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 < > > > > > daradu...@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 < > > > > > > > > > dsetrak...@apache.org> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 19, 2018 at 1:50 PM, Vyacheslav Daradur < > > > > > > > > > daradu...@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 > > > > > > > > > > > > > <dsetrak...@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.
