You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Vyacheslav Daradur <da...@gmail.com> on 2018/10/31 14:04:33 UTC

Re: Service grid redesign

Hi, Igniters! Good news!

Service Grid Redesign Phase 1 - is in Patch Available now.

Nikolay Izhikov has reviewed implementation.

However, we need additional review from other Ignite experts.

Here is an umbrella ticket [1] and PR [2].

Could someone step in and do the review?

[1] https://issues.apache.org/jira/browse/IGNITE-9607
[2] https://github.com/apache/ignite/pull/4434
On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <dm...@gmail.com> wrote:
>
> Pavel, could you assist?
>
> Does it make sense for .Net to specify service class name instead of its
> implementation?
>
> I think, it shouldn't be a problem.
>
> Denis
>
> On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <da...@gmail.com> wrote:
>
> > I think that the replacement of serialized instance makes sense to me
> > for Java part.
> >
> > But how it should work for .NET client?
> >
> > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <ds...@apache.org>
> > wrote:
> > >
> > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <ns...@gmail.com>
> > > wrote:
> > >
> > > > Hello, Igniters.
> > > >
> > > > I am working on task [1] that would replace serialized service's
> > instance
> > > > by service's class name and properties map in {ServiceConfiguration}.
> > > >
> > > > The task describes that we should use
> > > > {String className} + {Map<String, Object> properties} instead {Service
> > > > srvc}.
> > > >
> > > > I'd like to clarify the following questions:
> > > >
> > > > 1. What about public methods?
> > > > I suggest to mark them as deprecated and use class name of provided
> > > > instance.
> > > > Also to add deploying methods with new parameters:
> > > >
> > > > @Deprecated
> > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > String
> > > > name, Service svc)
> > > >
> > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > String
> > > > name, String srvcClsName, Map<String, Object> prop)
> > > >
> > >
> > > I think this makes sense, but I would like other committers to confirm.
> > > Perhaps Vladimir Ozerov should comment here.
> > >
> > >
> > > > 2. Is {Map<String, Object> properties} parameter mandatory when
> > deploying a
> > > > service?
> > > > Is it make sense to add deploying methods without it? For example:
> > > >
> > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > String
> > > > name, String srvcClsName)
> > > >
> > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > String
> > > > name, String srvcClsName, Map<String, Object> prop)
> > > >
> > >
> > > I would always ask the user to pass the property map, but would allow it
> > to
> > > be null.
> > >
> > > D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Yakov Zhdanov <yz...@apache.org>.
Nikolay, let me take a look at the changes. I will do it possibly over
weekend.

Thanks!

--Yakov

2018-11-08 17:20 GMT+03:00 Nikolay Izhikov <ni...@apache.org>:

> Hello, Igniters.
>
> Please, respond if anyone wish to do the additional review of this
> improvement.
>
> I think it's ready to be merged, so if noone has time to review, I can
> merge the patch.
>
> ср, 7 нояб. 2018 г., 18:04 Vyacheslav Daradur daradurvs@gmail.com:
>
> > Dmitriy, I published documentation in wiki:
> > https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=95654584
> >
> > Thank you!
> > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com>
> > wrote:
> > >
> > > Hi I think wiki is better than any attached docs. Could you please
> > create a
> > > page?
> > >
> > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > I prepared a description of the implemented solution and attached it
> > > > to the issue [1].
> > > >
> > > > This should help during a review. Should I post the document into
> wiki
> > or
> > > > IEP?
> > > >
> > > > I'd like to ask Ignite's experts review the solution [1] [2], please?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > [2] https://github.com/apache/ignite/pull/4434
> > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hi, Igniters! Good news!
> > > > >
> > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > >
> > > > > Nikolay Izhikov has reviewed implementation.
> > > > >
> > > > > However, we need additional review from other Ignite experts.
> > > > >
> > > > > Here is an umbrella ticket [1] and PR [2].
> > > > >
> > > > > Could someone step in and do the review?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > dmekhanikov@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Pavel, could you assist?
> > > > > >
> > > > > > Does it make sense for .Net to specify service class name instead
> > of
> > > > its
> > > > > > implementation?
> > > > > >
> > > > > > I think, it shouldn't be a problem.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I think that the replacement of serialized instance makes sense
> > to me
> > > > > > > for Java part.
> > > > > > >
> > > > > > > But how it should work for .NET client?
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > nsamelchev@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello, Igniters.
> > > > > > > > >
> > > > > > > > > I am working on task [1] that would replace serialized
> > service's
> > > > > > > instance
> > > > > > > > > by service's class name and properties map in
> > > > {ServiceConfiguration}.
> > > > > > > > >
> > > > > > > > > The task describes that we should use
> > > > > > > > > {String className} + {Map<String, Object> properties}
> instead
> > > > {Service
> > > > > > > > > srvc}.
> > > > > > > > >
> > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > >
> > > > > > > > > 1. What about public methods?
> > > > > > > > > I suggest to mark them as deprecated and use class name of
> > > > provided
> > > > > > > > > instance.
> > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > >
> > > > > > > > > @Deprecated
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, Service svc)
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I think this makes sense, but I would like other committers
> to
> > > > confirm.
> > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > >
> > > > > > > >
> > > > > > > > > 2. Is {Map<String, Object> properties} parameter mandatory
> > when
> > > > > > > deploying a
> > > > > > > > > service?
> > > > > > > > > Is it make sense to add deploying methods without it? For
> > > > example:
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName)
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I would always ask the user to pass the property map, but
> would
> > > > allow it
> > > > > > > to
> > > > > > > > be null.
> > > > > > > >
> > > > > > > > D.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Igniters.

Please, respond if anyone wish to do the additional review of this
improvement.

I think it's ready to be merged, so if noone has time to review, I can
merge the patch.

ср, 7 нояб. 2018 г., 18:04 Vyacheslav Daradur daradurvs@gmail.com:

> Dmitriy, I published documentation in wiki:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
>
> Thank you!
> On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com>
> wrote:
> >
> > Hi I think wiki is better than any attached docs. Could you please
> create a
> > page?
> >
> > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
> >
> > > I prepared a description of the implemented solution and attached it
> > > to the issue [1].
> > >
> > > This should help during a review. Should I post the document into wiki
> or
> > > IEP?
> > >
> > > I'd like to ask Ignite's experts review the solution [1] [2], please?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > [2] https://github.com/apache/ignite/pull/4434
> > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > > >
> > > > Hi, Igniters! Good news!
> > > >
> > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > >
> > > > Nikolay Izhikov has reviewed implementation.
> > > >
> > > > However, we need additional review from other Ignite experts.
> > > >
> > > > Here is an umbrella ticket [1] and PR [2].
> > > >
> > > > Could someone step in and do the review?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > [2] https://github.com/apache/ignite/pull/4434
> > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > wrote:
> > > > >
> > > > > Pavel, could you assist?
> > > > >
> > > > > Does it make sense for .Net to specify service class name instead
> of
> > > its
> > > > > implementation?
> > > > >
> > > > > I think, it shouldn't be a problem.
> > > > >
> > > > > Denis
> > > > >
> > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > > > >
> > > > > > I think that the replacement of serialized instance makes sense
> to me
> > > > > > for Java part.
> > > > > >
> > > > > > But how it should work for .NET client?
> > > > > >
> > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > nsamelchev@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello, Igniters.
> > > > > > > >
> > > > > > > > I am working on task [1] that would replace serialized
> service's
> > > > > > instance
> > > > > > > > by service's class name and properties map in
> > > {ServiceConfiguration}.
> > > > > > > >
> > > > > > > > The task describes that we should use
> > > > > > > > {String className} + {Map<String, Object> properties} instead
> > > {Service
> > > > > > > > srvc}.
> > > > > > > >
> > > > > > > > I'd like to clarify the following questions:
> > > > > > > >
> > > > > > > > 1. What about public methods?
> > > > > > > > I suggest to mark them as deprecated and use class name of
> > > provided
> > > > > > > > instance.
> > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > >
> > > > > > > > @Deprecated
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, Service svc)
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > >
> > > > > > >
> > > > > > > I think this makes sense, but I would like other committers to
> > > confirm.
> > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > >
> > > > > > >
> > > > > > > > 2. Is {Map<String, Object> properties} parameter mandatory
> when
> > > > > > deploying a
> > > > > > > > service?
> > > > > > > > Is it make sense to add deploying methods without it? For
> > > example:
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName)
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > >
> > > > > > >
> > > > > > > I would always ask the user to pass the property map, but would
> > > allow it
> > > > > > to
> > > > > > > be null.
> > > > > > >
> > > > > > > D.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis, thanks for your participation!

>> There is no exchange in case of service deployment
There is some kind of exchange of services map which describes mapping
services instances to nodes in the cluster.

I'm a bit confused because of your notes about naming, the main goal
was to do the code to be transparent for Ignites experts and to not
confuse them.

Also, the messages names and structure has been presented and
discussed with community [1] during a design overview.

[1] http://apache-ignite-developers.2346864.n4.nabble.com/Service-Grid-new-design-overview-td34201.html
On Tue, Nov 20, 2018 at 5:19 PM Denis Mekhanikov <dm...@gmail.com> wrote:
>
> Vyacheslav,
>
> I'm in process of reviewing your changes. Sorry for taking so long.
> I posted the first portion of review comments yesterday.
> I'd like to finish looking through the code. I'll post more comments later.
>
> I see, that you called things analogously to partition map exchange.
> I realize, that there is an analogy in used procedures, but I don't really
> like the idea to use the same names for everything.
> The partition map exchange is called this way because it involves an actual
> exchange of information.
> All nodes need to tell each other, which partitions they have, and what
> their states are.
>
> There is no exchange in case of service deployment, so I would skip the
> "exchange" part.
> And *single message ->* *full message* look more like *request -> response*
> in case of services.
>
> Suppose we abandon the PME procedure and move to something else.
> Then *ServiceDeploymentExchange* name won't make sense.
> And I don't want to be in a situation, when I say to my colleague a word
> "exchange",
> and get "which one?" in return.
> So, I'm for the meaningful names rather than analogous to something else.
>
> What do you think?
>
> Denis
>
> вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <da...@gmail.com>:
>
> > Denis, Yakov have you had a chance to review the solution?
> >
> > Igniters, we need to define a list of reviewers, otherwise no end in sign.
> >
> > I'm ready to continue work on the Service Grid, including new features
> > like hot-redeployment and versioning, also, I have ideas about new
> > tools for monitoring and management which will be useful for our
> > end-users.
> >
> > But for continuing work we need to overcome this first phase.
> >
> > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > >
> > > Denis, Yakov, feel free to contact me directly in case of questions.
> > Thanks!
> > >
> > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <dm...@gmail.com>
> > wrote:
> > > >
> > > > Guys,
> > > >
> > > > I'd like to take a look at the changes before they are merged.
> > > > I'll do my best to finish the review before the end of the upcoming
> > week.
> > > >
> > > > Thanks!
> > > > Denis
> > > >
> > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > > Hello, Vladimir.
> > > > >
> > > > > I'm agree with you.
> > > > >
> > > > > Can we write the list of reviewers for this feature?
> > > > > Without a date or similar.
> > > > > Just a list of experts who should review this feature.
> > > > >
> > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > Igniters,
> > > > > >
> > > > > > This is very huge thing with complex algorithms behind. We should
> > not
> > > > > merge
> > > > > > it to the product unless several additional thorough reviews are
> > ready,
> > > > > > irrespectively of how long will it take. We are about quality, not
> > speed.
> > > > > >
> > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > What are the cases when the service can be redeployed? Affinity,
> > > > > failure,
> > > > > > > etc., right. It would be good to list all the cases on the wiki
> > and
> > > > > then
> > > > > > > our tech writers will get everything documented.
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Services reassignment process takes into account previous
> > assignments
> > > > > > > > to avoid redundant redeployments.
> > > > > > > > So, in the described case, ServiceA won't be moved from node1
> > to
> > > > > node2.
> > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > First of all, thanks for archiving this milestone and
> > rolling out
> > > > > these
> > > > > > > >
> > > > > > > > new
> > > > > > > > > capabilities.
> > > > > > > > >
> > > > > > > > > Speaking of the topology change events [1], does the new
> > > > > architecture
> > > > > > > >
> > > > > > > > avoid
> > > > > > > > > a running service redeployment when a new node joins? For
> > instance,
> > > > > > >
> > > > > > > let's
> > > > > > > > > say I have ServiceA running node1, then node2 joins and I
> > don't
> > > > > want
> > > > > > >
> > > > > > > the
> > > > > > > > > service to be redeployed to any other node.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > >
> > > > > > > > > > Thank you!
> > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > dpavlov.spb@gmail.com
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi I think wiki is better than any attached docs. Could
> > you
> > > > > please
> > > > > > > > > >
> > > > > > > > > > create a
> > > > > > > > > > > page?
> > > > > > > > > > >
> > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > daradurvs@gmail.com
> > > > > > > >
> > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > I prepared a description of the implemented solution
> > and
> > > > > attached
> > > > > > > >
> > > > > > > > it
> > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > >
> > > > > > > > > > > > This should help during a review. Should I post the
> > document
> > > > > into
> > > > > > > >
> > > > > > > > wiki
> > > > > > > > > > or
> > > > > > > > > > > > IEP?
> > > > > > > > > > > >
> > > > > > > > > > > > I'd like to ask Ignite's experts review the solution
> > [1] [2],
> > > > > > > >
> > > > > > > > please?
> > > > > > > > > > > >
> > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > > > > > >
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > >
> > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > Available now.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > >
> > > > > > > > > > > > > However, we need additional review from other Ignite
> > > > > experts.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > >
> > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > > > > > >
> > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Does it make sense for .Net to specify service
> > class name
> > > > > > > >
> > > > > > > > instead
> > > > > > > > > > of
> > > > > > > > > > > > its
> > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > > > > > >
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think that the replacement of serialized
> > instance
> > > > > makes
> > > > > > > >
> > > > > > > > sense
> > > > > > > > > > to me
> > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > Setrakyan <
> > > > > > > > > > > >
> > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > Amelchev <
> > > > > > > > > > > >
> > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I am working on task [1] that would replace
> > > > > serialized
> > > > > > > > > >
> > > > > > > > > > service's
> > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > by service's class name and properties map in
> > > > > > > > > > > >
> > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > > > properties}
> > > > > > > >
> > > > > > > > instead
> > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > I suggest to mark them as deprecated and use
> > class
> > > > > name
> > > > > > > >
> > > > > > > > of
> > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > parameters:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > Object> prop)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think this makes sense, but I would like
> > other
> > > > > > > >
> > > > > > > > committers to
> > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > parameter
> > > > > > > >
> > > > > > > > mandatory
> > > > > > > > > > when
> > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > Is it make sense to add deploying methods
> > without
> > > > > it?
> > > > > > >
> > > > > > > For
> > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > Object> prop)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I would always ask the user to pass the
> > property
> > > > > map, but
> > > > > > > >
> > > > > > > > would
> > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Vladimir.

> There is no "exchange", instead nodes send
information to coordinator that they finished some operation
1. Each node sends to coordinator local deployments results.
2. Coordinator sends to each node full deployment map.

This is the same process we have in PME for me.
What have I miss?

21 нояб. 2018 г. 11:04 AM пользователь "Vladimir Ozerov" <
vozerov@gridgain.com> написал:

I do not know what is correct term :-) What I said is that "exchange" is
counter intuitive here. There is no "exchange", instead nodes send
information to coordinator that they finished some operation. E.g. we do
the same for schema changes (index creation), and as Denis suggested,
Request-Response is correct suffixes here. Message name should explain what
really happened, instead of describing things which are somewhat similar in
internal flow.


On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
wrote:

> Hello, Vladimir.
>
> What is correct term?
>
>
> ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
>
> > Agree. Service deployment has nothing to do with PME. We should not use
> the
> > same term for different things.
> >
> > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:
> >
> > > Vyacheslav,
> > >
> > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > I posted the first portion of review comments yesterday.
> > > I'd like to finish looking through the code. I'll post more comments
> > later.
> > >
> > > I see, that you called things analogously to partition map exchange.
> > > I realize, that there is an analogy in used procedures, but I don't
> > really
> > > like the idea to use the same names for everything.
> > > The partition map exchange is called this way because it involves an
> > actual
> > > exchange of information.
> > > All nodes need to tell each other, which partitions they have, and
what
> > > their states are.
> > >
> > > There is no exchange in case of service deployment, so I would skip
the
> > > "exchange" part.
> > > And *single message ->* *full message* look more like *request ->
> > response*
> > > in case of services.
> > >
> > > Suppose we abandon the PME procedure and move to something else.
> > > Then *ServiceDeploymentExchange* name won't make sense.
> > > And I don't want to be in a situation, when I say to my colleague a
> word
> > > "exchange",
> > > and get "which one?" in return.
> > > So, I'm for the meaningful names rather than analogous to something
> else.
> > >
> > > What do you think?
> > >
> > > Denis
> > >
> > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <daradurvs@gmail.com
> >:
> > >
> > > > Denis, Yakov have you had a chance to review the solution?
> > > >
> > > > Igniters, we need to define a list of reviewers, otherwise no end in
> > > sign.
> > > >
> > > > I'm ready to continue work on the Service Grid, including new
> features
> > > > like hot-redeployment and versioning, also, I have ideas about new
> > > > tools for monitoring and management which will be useful for our
> > > > end-users.
> > > >
> > > > But for continuing work we need to overcome this first phase.
> > > >
> > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > >
> > > > > Denis, Yakov, feel free to contact me directly in case of
> questions.
> > > > Thanks!
> > > > >
> > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Guys,
> > > > > >
> > > > > > I'd like to take a look at the changes before they are merged.
> > > > > > I'll do my best to finish the review before the end of the
> upcoming
> > > > week.
> > > > > >
> > > > > > Thanks!
> > > > > > Denis
> > > > > >
> > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> nizhikov@apache.org
> > >:
> > > > > >
> > > > > > > Hello, Vladimir.
> > > > > > >
> > > > > > > I'm agree with you.
> > > > > > >
> > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > Without a date or similar.
> > > > > > > Just a list of experts who should review this feature.
> > > > > > >
> > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > This is very huge thing with complex algorithms behind. We
> > should
> > > > not
> > > > > > > merge
> > > > > > > > it to the product unless several additional thorough reviews
> > are
> > > > ready,
> > > > > > > > irrespectively of how long will it take. We are about
> quality,
> > > not
> > > > speed.
> > > > > > > >
> > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dmagda@apache.org
> >:
> > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > What are the cases when the service can be redeployed?
> > > Affinity,
> > > > > > > failure,
> > > > > > > > > etc., right. It would be good to list all the cases on the
> > wiki
> > > > and
> > > > > > > then
> > > > > > > > > our tech writers will get everything documented.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > Services reassignment process takes into account
previous
> > > > assignments
> > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > So, in the described case, ServiceA won't be moved from
> > node1
> > > > to
> > > > > > > node2.
> > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > dmagda@apache.org>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > First of all, thanks for archiving this milestone and
> > > > rolling out
> > > > > > > these
> > > > > > > > > >
> > > > > > > > > > new
> > > > > > > > > > > capabilities.
> > > > > > > > > > >
> > > > > > > > > > > Speaking of the topology change events [1], does the
> new
> > > > > > > architecture
> > > > > > > > > >
> > > > > > > > > > avoid
> > > > > > > > > > > a running service redeployment when a new node joins?
> For
> > > > instance,
> > > > > > > > >
> > > > > > > > > let's
> > > > > > > > > > > say I have ServiceA running node1, then node2 joins
> and I
> > > > don't
> > > > > > > want
> > > > > > > > >
> > > > > > > > > the
> > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> >
>
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you!
> > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi I think wiki is better than any attached docs.
> > Could
> > > > you
> > > > > > > please
> > > > > > > > > > > >
> > > > > > > > > > > > create a
> > > > > > > > > > > > > page?
> > > > > > > > > > > > >
> > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > >
> > > > > > > > > > :
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I prepared a description of the implemented
> > solution
> > > > and
> > > > > > > attached
> > > > > > > > > >
> > > > > > > > > > it
> > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This should help during a review. Should I post
> the
> > > > document
> > > > > > > into
> > > > > > > > > >
> > > > > > > > > > wiki
> > > > > > > > > > > > or
> > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > solution
> > > > [1] [2],
> > > > > > > > > >
> > > > > > > > > > please?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > Available now.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > However, we need additional review from other
> > > Ignite
> > > > > > > experts.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > Mekhanikov <
> > > > > > > > > > > >
> > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> service
> > > > class name
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > of
> > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think that the replacement of serialized
> > > > instance
> > > > > > > makes
> > > > > > > > > >
> > > > > > > > > > sense
> > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > Setrakyan <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > > > Amelchev <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > replace
> > > > > > > serialized
> > > > > > > > > > > >
> > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > by service's class name and properties
> > map
> > > in
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> Object>
> > > > > > > properties}
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > questions:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > I suggest to mark them as deprecated
> and
> > > use
> > > > class
> > > > > > > name
> > > > > > > > > >
> > > > > > > > > > of
> > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > > > parameters:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think this makes sense, but I would
> like
> > > > other
> > > > > > > > > >
> > > > > > > > > > committers to
> > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment
> > here.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > > > parameter
> > > > > > > > > >
> > > > > > > > > > mandatory
> > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> methods
> > > > without
> > > > > > > it?
> > > > > > > > >
> > > > > > > > > For
> > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I would always ask the user to pass the
> > > > property
> > > > > > > map, but
> > > > > > > > > >
> > > > > > > > > > would
> > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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.
> > > >
> > >
> >
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis, thank you! I’m glad to participate in development of the project.

Unfortunately, we don’t have clear design of the services hot redeployment
yet.

I’m going to start discussions about Service Grid roadmap and services hot
redevelopment design in separate threads within a couple of weeks.


пт, 18 янв. 2019 г. в 0:06, Denis Magda <dm...@apache.org>:

> Vyacheslav,
>
> Let me speak for the community and Ignite users and thank you for achieving
> this milestone! Seems that the foundation for much bigger and impactful
> improvements is ready. Tremendous job.
>
> Are you going to start working on the services hot redeployment next?
>
>
> -
> Denis
>
>
> On Wed, Jan 16, 2019 at 1:36 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > The wiki's article [1] has been updated according to the merged solution
> > [2].
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > [2] https://issues.apache.org/jira/browse/IGNITE-9607
> >
> > On Fri, Dec 28, 2018 at 1:10 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > >
> > > Igniters,
> > >
> > > to have an opportunity to test both new and old service grid
> > > implementations, we added new config-plans on TC:
> > > - Service Grid [1] - runs tests in new (default) mode
> > > - Service Grid (legacy mode) [2] - runs tests in old (legacy) mode
> > >
> > > Both plans contain the following test-suites:
> > > - IgniteServiceGridTestSuite (newly added suite)
> > > - IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic
> > 2")
> > >
> > > Also, the plans have been included in RunAll.
> > >
> > > [1]
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid
> > > [2]
> >
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
> > >
> > > On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov <ni...@apache.org>
> > wrote:
> > > >
> > > > Hello, Igniters.
> > > >
> > > > I've merged Service Grid Redesign - Phase 1 to the master.
> > > > Vyacheslav, great contribution!
> > > >
> > > > Thanks for all Ignite veterans both for the code and design review.
> > > >
> > > > В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> > > > > Hello, Igniters.
> > > > >
> > > > > Please, let us know, if someone want to do additional review of
> this
> > PR.
> > > > >
> > > > > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > > > > > Igniters, especially future reviewers,
> > > > > >
> > > > > > Discovery listener registered by 'IgniteServiceProcessor' become
> > > > > > implemented 'HighPriorityListener', seems it's best lock-free
> > > > > > solutions discussed during the review. This change is covered by
> > > > > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which
> > should
> > > > > > protect us if the order of listeners will be changed.
> > > > > >
> > > > > > It's about the problem of custom messages which are nullified by
> > PME
> > > > > > [1] and are listened by service deployment to manage the
> lifecycle
> > of
> > > > > > affinity services. This guarantees that service deployment
> > discovery
> > > > > > listener will be notified earlier than PME's discovery listener
> and
> > > > > > will be able to capture custom messages which may be nullified in
> > PME
> > > > > > process.
> > > > > >
> > > > > > Looks like we do not have any controversial questions now.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > > > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > > > > >
> > > > > >
> > > > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <
> > daradurvs@gmail.com> wrote:
> > > > > > >
> > > > > > > Stanislav, thank you for the notes, most of them have been
> > resolved. I
> > > > > > > answered on GitHub.
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > > > > > <st...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I’ve done a quick superficial review. Didn’t look at the
> > tests, didn’t dive into the design, etc, just the code.
> > > > > > > > I’ve left some comments – almost all are about minor issues,
> > grammar and code style.
> > > > > > > >
> > > > > > > > Stan
> > > > > > > >
> > > > > > > > From: Vyacheslav Daradur
> > > > > > > > Sent: 21 декабря 2018 г. 14:58
> > > > > > > > To: dev@ignite.apache.org
> > > > > > > > Subject: Re: Service grid redesign
> > > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > Please, let us know if someone is going to do an additional
> > review?
> > > > > > > >
> > > > > > > > We should know can we merge the PR since it has been approved
> > by
> > > > > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for
> > other
> > > > > > > > community members.
> > > > > > > >
> > > > > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <
> > daradurvs@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > I think I found names which should satisfy me and Denis,
> and
> > possibly Nikolay )
> > > > > > > > >
> > > > > > > > > See the following names (Actual name <- Previously used):
> > > > > > > > >
> > > > > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > > > > >
> > > > > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > > > > >
> > > > > > > > > - ServiceSingleNodeDeploymentResult <-
> > ServiceSingleDeploymentsResults
> > > > > > > > > - ServiceSingleNodeDeploymentResultBatch <-
> > ServicesSingleDeploymentsMessage
> > > > > > > > >
> > > > > > > > > - ServiceClusterDeploymentResult <-
> > ServiceFullDeploymentsResults
> > > > > > > > > - ServiceClusterDeploymentResultBatch <-
> > ServicesFullDeploymentsMessage
> > > > > > > > >
> > > > > > > > > - ServiceProcessorCommonDiscoveryData <-
> > ServicesCommonDiscoveryData
> > > > > > > > > - ServiceProcessorJoinNodeDiscoveryData <-
> > ServicesJoinNodeDiscoveryData
> > > > > > > > >
> > > > > > > > > Also, I had a short talk with Alexey Goncharuk about the
> > problem of
> > > > > > > > > nullified custom messages. I changed the implementation to
> a
> > lock-free
> > > > > > > > > solution which allows us to nullify messages depend on an
> > using
> > > > > > > > > counter.
> > > > > > > > >
> > > > > > > > > In comparison with high priority listener, this allows us
> to
> > not copy
> > > > > > > > > custom discovery event in service deployment manager and
> > work with the
> > > > > > > > > original object.
> > > > > > > > >
> > > > > > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <
> > nizhikov@apache.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Denis, great news!
> > > > > > > > > >
> > > > > > > > > > Alexey, Vova, Yakov, do you want to take a look at this
> PR?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > Guys,
> > > > > > > > > > >
> > > > > > > > > > > I finished my code review. The pool request looks good
> > to me.
> > > > > > > > > > >
> > > > > > > > > > > Does anybody else want to look at the changes?
> > > > > > > > > > > There are a few points, that we didn't meet an
> agreement
> > on,
> > > > > > > > > > > though they don't affect the behaviour in any way:
> > > > > > > > > > >
> > > > > > > > > > >    - *Class naming. * See the discussion above.
> > > > > > > > > > >    - *Unnecessary task object cleaning. *
> > > > > > > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't
> do
> > anything useful,
> > > > > > > > > > >    and it should be removed.
> > > > > > > > > > >    By the moment, when this method is called, the task
> > object is removed
> > > > > > > > > > >    from all collections anyway, so it's ready for
> > garbage collection.
> > > > > > > > > > >    Removing data from it doesn't help anybody.
> > > > > > > > > > >    -
> > > > > > > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > > > > > > >    ServicesDeploymentProcessIdSelfTest look excessive
> to
> > me.
> > > > > > > > > > >    I don't see any point in testing an interface
> > implementation, that only
> > > > > > > > > > >    saves some objects and returns them from certain
> > methods.
> > > > > > > > > > >    - Interface for events with
> > servicesDeploymentActions() method.
> > > > > > > > > > >    Take a look at the discussion:
> > > > > > > > > > >
> >
> https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > > > > >
> > > > > > > > > > > Also solution with
> > *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > > > > > clumsy to me.
> > > > > > > > > > > The problem with nullifying of
> > *DiscoveryCustomEvent#customMsg* field can
> > > > > > > > > > > be solved
> > > > > > > > > > > by making *ServiceDiscoveryListener* a high priority
> > listener.
> > > > > > > > > > >
> > > > > > > > > > > Or *DiscoveryCustomEvent#customMessage()* method could
> > be marked
> > > > > > > > > > > synchronized and
> > > > > > > > > > > *GridEventStorageManager#notifyListeners(..)* method
> > could synchronize on
> > > > > > > > > > > the event object.
> > > > > > > > > > > But this solution is the same, it's just a matter of
> > taste.
> > > > > > > > > > >
> > > > > > > > > > > If anybody wants to look the the code of the PR, please
> > consider these
> > > > > > > > > > > points as well.
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <
> > nizhikov@apache.org>:
> > > > > > > > > > >
> > > > > > > > > > > > Denis,
> > > > > > > > > > > >
> > > > > > > > > > > > I don't think that differences with your and my
> naming
> > is huge :)
> > > > > > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > > > > >
> > > > > > > > > > > > If there is no any other issues with PR let's rename
> > and move on! :)
> > > > > > > > > > > >
> > > > > > > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <
> > daradurvs@gmail.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > > > We have IgniteServiceProcessor and
> > GridServiceProcessor with singular
> > > > > > > > > > > > >
> > > > > > > > > > > > > "Service"
> > > > > > > > > > > > >
> > > > > > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor'
> > to
> > > > > > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > > > > >
> > > > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't
> > make sense to me.
> > > > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 'Single' means 'single node', maybe we should use
> > one of the following:
> > > > > > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <
> > dmekhanikov@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Slava,
> > > > > > > > > > > > > > I think, it's better to replace word "Change"
> with
> > "Request".
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Nik,
> > > > > > > > > > > > > > We have IgniteServiceProcessor and
> > GridServiceProcessor with singular
> > > > > > > > > > > > > > "Service",
> > > > > > > > > > > > > > ServicesDeploymentManager and
> > ServicesDeploymentTask with plural
> > > > > > > > > > > > >
> > > > > > > > > > > > > "Services"
> > > > > > > > > > > > > > for some reason.
> > > > > > > > > > > > > > So, you need to remember, where Service and where
> > Services is used.
> > > > > > > > > > > > > > I think, we should unify these names.
> > > > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't
> > make sense to me.
> > > > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > > > > > It doesn't really reflect its function. This
> > message is supposed to
> > > > > > > > > > > >
> > > > > > > > > > > > mark
> > > > > > > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <
> > daradurvs@gmail.com>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *1. Testing of the cache-based implementation
> > of the service grid.*
> > > > > > > > > > > > > > > > I think, we should make a test suite, that
> > will test the old
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agree. This is exactly what should be done as
> > the first step once
> > > > > > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > > > > > I think all tests in the package:
> > > > > > > > > > > > > > > "org.apache.ignite.internal.processors.service"
> > should be moved to
> > > > > > > > > > > > > > > separate test-suite and new build-plan should
> be
> > added on TC and
> > > > > > > > > > > > > > > included in RunAll.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Personally, I agree, but I have faced
> opposition
> > at the design step.
> > > > > > > > > > > > > > > I changed to the following structure:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > abstract class ServiceAbstractChange implements
> > Serializable {
> > > > > > > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > class ServiceDeploymentChange extends
> > ServiceAbstractChange {
> > > > > > > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > > > > > > }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > class ServiceUndeploymentChange extends
> > ServiceAbstractChange { }
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I hope that further reviewers will agree with
> us.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > About "Services" -> "Service" and "Deployments"
> > -> "Deployment"
> > > > > > > > > > > > > > > Personally, I agree with Nikolay, because it's
> > more descriptive since
> > > > > > > > > > > > > > > manages several services, not single.
> > > > > > > > > > > > > > > But, I understand Denis's point of view, we
> have
> > a lot of classes
> > > > > > > > > > > >
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > "Service" prefix in naming and "Services" looks
> > a bit alien.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > > >
> > > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > > Prefix "Dynamic" has no sense anymore since we
> > reworked message
> > > > > > > > > > > > > > > structure as in p.2. so
> > "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > > > > > name.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage ->
> > ServiceDeploymentResponse*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > It's not a response and is not sent to the
> > sender. This message is
> > > > > > > > > > > > > > > sent to the coordinator and contains *single
> > node* deployments.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This should be named similar way as the
> previous
> > one, but the message
> > > > > > > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay
> Izhikov
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Great news.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *1. Testing of the cache-based
> > implementation of the service
> > > > > > > > > > > >
> > > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > > I think, we should make a test suite, that
> > will test the old
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > implementation> until we> remove it from the
> > project.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > > I think, this class should be splat into
> two.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> > *ServicesDeploymentTask *and all
> > > > > > > > > > > >
> > > > > > > > > > > > other
> > > > > > > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > > > > > > I think, they would look better if we use a
> > singular word
> > > > > > > > > > > >
> > > > > > > > > > > > *Service
> > > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Personally, I want that names as clearly as
> > possible reflects class
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > content for reader.
> > > > > > > > > > > > > > > > If we deploy *several* services then it has
> to
> > be Service*S*.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Same for deployment - if this message will
> > initiate single
> > > > > > > > > > > >
> > > > > > > > > > > > deployment
> > > > > > > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So my opinion - it's better to keep current
> > naming.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis
> > Mekhanikov пишет:
> > > > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I've been looking through the PR by
> > Vyacheslav for past few
> > > > > > > > > > > >
> > > > > > > > > > > > weeks.
> > > > > > > > > > > > > > > > > Slava, great job! You've done an impressive
> > amount of work.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I posted my comments to the PR and had a
> few
> > calls with Slava.
> > > > > > > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > > > > > > There are some points, that I'd like to
> > settle in this discussion
> > > > > > > > > > > > >
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *1. Testing of the cache-based
> > implementation of the service
> > > > > > > > > > > >
> > > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > > I think, we should make a test suite, that
> > will test the old
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > > until we
> > > > > > > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > > I think, this class should be splat into
> two.
> > > > > > > > > > > > > > > > > I don't see any point in having a single
> > class with "*flags"*
> > > > > > > > > > > > >
> > > > > > > > > > > > > field,
> > > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > > > > > > Usage of *deploy(), markDeploy(...),
> > undeploy(),
> > > > > > > > > > > >
> > > > > > > > > > > > markUndeploy(...)*
> > > > > > > > > > > > > > > looks
> > > > > > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > > > > > Why not have a separate message type for
> > each action instead?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> > *ServicesDeploymentTask *and all
> > > > > > > > > > > >
> > > > > > > > > > > > other
> > > > > > > > > > > > > > > classes
> > > > > > > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > > > > > > I think, they would look better if we use a
> > singular word
> > > > > > > > > > > >
> > > > > > > > > > > > *Service
> > > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *ServicesDeploymentManager ->
> > ServiceDeploymentManager*
> > > > > > > > > > > > > > > > > *ServicesDeploymentActions ->
> > ServiceDeploymentActions*
> > > > > > > > > > > > > > > > > *ServicesDeploymentTask ->
> > ServiceDeploymentTask*
> > > > > > > > > > > > > > > > > *ServicesCommonDiscoveryData ->
> > ServiceCommonDiscoveryData*
> > > > > > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > > > > > >
> > > > > > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage
> ->
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage ->
> > ServiceDeploymentResponse*
> > > > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > > > > > >
> > > > > > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > > > > > >
> > > > > > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > > > > > *ServiceFullDeploymentsResults ->
> > ServiceFullDeploymentResult*
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Let's do this as the final step of the code
> > review to avoid
> > > > > > > > > > > > >
> > > > > > > > > > > > > repeated
> > > > > > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis
> Mekhanikov
> > <
> > > > > > > > > > > > >
> > > > > > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I don't see any problem in letting
> > services work on a
> > > > > > > > > > > >
> > > > > > > > > > > > deactivated
> > > > > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > > > > All services need is discovery messages
> > and compute tasks.
> > > > > > > > > > > > > > > > > > Both of these features are available at
> > all times.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But it should be configurable. Services
> > may need caches for
> > > > > > > > > > > >
> > > > > > > > > > > > their
> > > > > > > > > > > > > > > work,
> > > > > > > > > > > > > > > > > > so it's better to undeploy such services
> > on cluster
> > > > > > > > > > > >
> > > > > > > > > > > > deactivation.
> > > > > > > > > > > > > > > > > > We may introduce a new property in
> > ServiceConfiguration.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think, this topic deserves a separate
> > discussion.
> > > > > > > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey
> > Kuznetsov <
> > > > > > > > > > > > >
> > > > > > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'm thinking about to use Services API
> > to implement Web Agent
> > > > > > > > > > > > >
> > > > > > > > > > > > > as a
> > > > > > > > > > > > > > > cluster
> > > > > > > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > > > > > > It will improve Web Console UX, because
> > it will not needed to
> > > > > > > > > > > > >
> > > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > > > > > > Just start cluster with Web agent
> > enabled on cluster
> > > > > > > > > > > > >
> > > > > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But in order to do this, I need that
> > services should:
> > > > > > > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > > > > > >   2) Auto restart with cluster (when
> > cluster was restarted).
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Could we support mentioned features on
> > "Service Grid
> > > > > > > > > > > >
> > > > > > > > > > > > redesign -
> > > > > > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > 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.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Denis Magda <dm...@apache.org>.
Vyacheslav,

Let me speak for the community and Ignite users and thank you for achieving
this milestone! Seems that the foundation for much bigger and impactful
improvements is ready. Tremendous job.

Are you going to start working on the services hot redeployment next?


-
Denis


On Wed, Jan 16, 2019 at 1:36 AM Vyacheslav Daradur <da...@gmail.com>
wrote:

> The wiki's article [1] has been updated according to the merged solution
> [2].
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> [2] https://issues.apache.org/jira/browse/IGNITE-9607
>
> On Fri, Dec 28, 2018 at 1:10 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
> >
> > Igniters,
> >
> > to have an opportunity to test both new and old service grid
> > implementations, we added new config-plans on TC:
> > - Service Grid [1] - runs tests in new (default) mode
> > - Service Grid (legacy mode) [2] - runs tests in old (legacy) mode
> >
> > Both plans contain the following test-suites:
> > - IgniteServiceGridTestSuite (newly added suite)
> > - IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic
> 2")
> >
> > Also, the plans have been included in RunAll.
> >
> > [1]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid
> > [2]
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
> >
> > On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
> > >
> > > Hello, Igniters.
> > >
> > > I've merged Service Grid Redesign - Phase 1 to the master.
> > > Vyacheslav, great contribution!
> > >
> > > Thanks for all Ignite veterans both for the code and design review.
> > >
> > > В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> > > > Hello, Igniters.
> > > >
> > > > Please, let us know, if someone want to do additional review of this
> PR.
> > > >
> > > > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > > > > Igniters, especially future reviewers,
> > > > >
> > > > > Discovery listener registered by 'IgniteServiceProcessor' become
> > > > > implemented 'HighPriorityListener', seems it's best lock-free
> > > > > solutions discussed during the review. This change is covered by
> > > > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which
> should
> > > > > protect us if the order of listeners will be changed.
> > > > >
> > > > > It's about the problem of custom messages which are nullified by
> PME
> > > > > [1] and are listened by service deployment to manage the lifecycle
> of
> > > > > affinity services. This guarantees that service deployment
> discovery
> > > > > listener will be notified earlier than PME's discovery listener and
> > > > > will be able to capture custom messages which may be nullified in
> PME
> > > > > process.
> > > > >
> > > > > Looks like we do not have any controversial questions now.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > > > >
> > > > >
> > > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <
> daradurvs@gmail.com> wrote:
> > > > > >
> > > > > > Stanislav, thank you for the notes, most of them have been
> resolved. I
> > > > > > answered on GitHub.
> > > > > >
> > > > > >
> > > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > > > > <st...@gmail.com> wrote:
> > > > > > >
> > > > > > > I’ve done a quick superficial review. Didn’t look at the
> tests, didn’t dive into the design, etc, just the code.
> > > > > > > I’ve left some comments – almost all are about minor issues,
> grammar and code style.
> > > > > > >
> > > > > > > Stan
> > > > > > >
> > > > > > > From: Vyacheslav Daradur
> > > > > > > Sent: 21 декабря 2018 г. 14:58
> > > > > > > To: dev@ignite.apache.org
> > > > > > > Subject: Re: Service grid redesign
> > > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > Please, let us know if someone is going to do an additional
> review?
> > > > > > >
> > > > > > > We should know can we merge the PR since it has been approved
> by
> > > > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for
> other
> > > > > > > community members.
> > > > > > >
> > > > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <
> daradurvs@gmail.com> wrote:
> > > > > > > >
> > > > > > > > I think I found names which should satisfy me and Denis, and
> possibly Nikolay )
> > > > > > > >
> > > > > > > > See the following names (Actual name <- Previously used):
> > > > > > > >
> > > > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > > > >
> > > > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > > > >
> > > > > > > > - ServiceSingleNodeDeploymentResult <-
> ServiceSingleDeploymentsResults
> > > > > > > > - ServiceSingleNodeDeploymentResultBatch <-
> ServicesSingleDeploymentsMessage
> > > > > > > >
> > > > > > > > - ServiceClusterDeploymentResult <-
> ServiceFullDeploymentsResults
> > > > > > > > - ServiceClusterDeploymentResultBatch <-
> ServicesFullDeploymentsMessage
> > > > > > > >
> > > > > > > > - ServiceProcessorCommonDiscoveryData <-
> ServicesCommonDiscoveryData
> > > > > > > > - ServiceProcessorJoinNodeDiscoveryData <-
> ServicesJoinNodeDiscoveryData
> > > > > > > >
> > > > > > > > Also, I had a short talk with Alexey Goncharuk about the
> problem of
> > > > > > > > nullified custom messages. I changed the implementation to a
> lock-free
> > > > > > > > solution which allows us to nullify messages depend on an
> using
> > > > > > > > counter.
> > > > > > > >
> > > > > > > > In comparison with high priority listener, this allows us to
> not copy
> > > > > > > > custom discovery event in service deployment manager and
> work with the
> > > > > > > > original object.
> > > > > > > >
> > > > > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <
> nizhikov@apache.org> wrote:
> > > > > > > > >
> > > > > > > > > Denis, great news!
> > > > > > > > >
> > > > > > > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > Guys,
> > > > > > > > > >
> > > > > > > > > > I finished my code review. The pool request looks good
> to me.
> > > > > > > > > >
> > > > > > > > > > Does anybody else want to look at the changes?
> > > > > > > > > > There are a few points, that we didn't meet an agreement
> on,
> > > > > > > > > > though they don't affect the behaviour in any way:
> > > > > > > > > >
> > > > > > > > > >    - *Class naming. * See the discussion above.
> > > > > > > > > >    - *Unnecessary task object cleaning. *
> > > > > > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do
> anything useful,
> > > > > > > > > >    and it should be removed.
> > > > > > > > > >    By the moment, when this method is called, the task
> object is removed
> > > > > > > > > >    from all collections anyway, so it's ready for
> garbage collection.
> > > > > > > > > >    Removing data from it doesn't help anybody.
> > > > > > > > > >    -
> > > > > > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > > > > > >    ServicesDeploymentProcessIdSelfTest look excessive to
> me.
> > > > > > > > > >    I don't see any point in testing an interface
> implementation, that only
> > > > > > > > > >    saves some objects and returns them from certain
> methods.
> > > > > > > > > >    - Interface for events with
> servicesDeploymentActions() method.
> > > > > > > > > >    Take a look at the discussion:
> > > > > > > > > >
> https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > > > >
> > > > > > > > > > Also solution with
> *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > > > > clumsy to me.
> > > > > > > > > > The problem with nullifying of
> *DiscoveryCustomEvent#customMsg* field can
> > > > > > > > > > be solved
> > > > > > > > > > by making *ServiceDiscoveryListener* a high priority
> listener.
> > > > > > > > > >
> > > > > > > > > > Or *DiscoveryCustomEvent#customMessage()* method could
> be marked
> > > > > > > > > > synchronized and
> > > > > > > > > > *GridEventStorageManager#notifyListeners(..)* method
> could synchronize on
> > > > > > > > > > the event object.
> > > > > > > > > > But this solution is the same, it's just a matter of
> taste.
> > > > > > > > > >
> > > > > > > > > > If anybody wants to look the the code of the PR, please
> consider these
> > > > > > > > > > points as well.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <
> nizhikov@apache.org>:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > I don't think that differences with your and my naming
> is huge :)
> > > > > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > > > >
> > > > > > > > > > > If there is no any other issues with PR let's rename
> and move on! :)
> > > > > > > > > > >
> > > > > > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <
> daradurvs@gmail.com>:
> > > > > > > > > > >
> > > > > > > > > > > > > We have IgniteServiceProcessor and
> GridServiceProcessor with singular
> > > > > > > > > > > >
> > > > > > > > > > > > "Service"
> > > > > > > > > > > >
> > > > > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor'
> to
> > > > > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > > > >
> > > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't
> make sense to me.
> > > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > > >
> > > > > > > > > > > > 'Single' means 'single node', maybe we should use
> one of the following:
> > > > > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Slava,
> > > > > > > > > > > > > I think, it's better to replace word "Change" with
> "Request".
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nik,
> > > > > > > > > > > > > We have IgniteServiceProcessor and
> GridServiceProcessor with singular
> > > > > > > > > > > > > "Service",
> > > > > > > > > > > > > ServicesDeploymentManager and
> ServicesDeploymentTask with plural
> > > > > > > > > > > >
> > > > > > > > > > > > "Services"
> > > > > > > > > > > > > for some reason.
> > > > > > > > > > > > > So, you need to remember, where Service and where
> Services is used.
> > > > > > > > > > > > > I think, we should unify these names.
> > > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't
> make sense to me.
> > > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > > > > It doesn't really reflect its function. This
> message is supposed to
> > > > > > > > > > >
> > > > > > > > > > > mark
> > > > > > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <
> daradurvs@gmail.com>:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > *1. Testing of the cache-based implementation
> of the service grid.*
> > > > > > > > > > > > > > > I think, we should make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agree. This is exactly what should be done as
> the first step once
> > > > > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > > > > I think all tests in the package:
> > > > > > > > > > > > > > "org.apache.ignite.internal.processors.service"
> should be moved to
> > > > > > > > > > > > > > separate test-suite and new build-plan should be
> added on TC and
> > > > > > > > > > > > > > included in RunAll.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Personally, I agree, but I have faced opposition
> at the design step.
> > > > > > > > > > > > > > I changed to the following structure:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > abstract class ServiceAbstractChange implements
> Serializable {
> > > > > > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > class ServiceDeploymentChange extends
> ServiceAbstractChange {
> > > > > > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > > > > > }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > class ServiceUndeploymentChange extends
> ServiceAbstractChange { }
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > About "Services" -> "Service" and "Deployments"
> -> "Deployment"
> > > > > > > > > > > > > > Personally, I agree with Nikolay, because it's
> more descriptive since
> > > > > > > > > > > > > > manages several services, not single.
> > > > > > > > > > > > > > But, I understand Denis's point of view, we have
> a lot of classes
> > > > > > > > > > >
> > > > > > > > > > > with
> > > > > > > > > > > > > > "Service" prefix in naming and "Services" looks
> a bit alien.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > >
> > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > Prefix "Dynamic" has no sense anymore since we
> reworked message
> > > > > > > > > > > > > > structure as in p.2. so
> "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > > > > name.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage ->
> ServiceDeploymentResponse*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's not a response and is not sent to the
> sender. This message is
> > > > > > > > > > > > > > sent to the coordinator and contains *single
> node* deployments.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This should be named similar way as the previous
> one, but the message
> > > > > > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov
> <
> > > > > > > > > > >
> > > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Great news.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *1. Testing of the cache-based
> implementation of the service
> > > > > > > > > > >
> > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > I think, we should make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation> until we> remove it from the
> project.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> *ServicesDeploymentTask *and all
> > > > > > > > > > >
> > > > > > > > > > > other
> > > > > > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > > > > > I think, they would look better if we use a
> singular word
> > > > > > > > > > >
> > > > > > > > > > > *Service
> > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Personally, I want that names as clearly as
> possible reflects class
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > content for reader.
> > > > > > > > > > > > > > > If we deploy *several* services then it has to
> be Service*S*.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Same for deployment - if this message will
> initiate single
> > > > > > > > > > >
> > > > > > > > > > > deployment
> > > > > > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > So my opinion - it's better to keep current
> naming.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis
> Mekhanikov пишет:
> > > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I've been looking through the PR by
> Vyacheslav for past few
> > > > > > > > > > >
> > > > > > > > > > > weeks.
> > > > > > > > > > > > > > > > Slava, great job! You've done an impressive
> amount of work.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I posted my comments to the PR and had a few
> calls with Slava.
> > > > > > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > > > > > There are some points, that I'd like to
> settle in this discussion
> > > > > > > > > > > >
> > > > > > > > > > > > to
> > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *1. Testing of the cache-based
> implementation of the service
> > > > > > > > > > >
> > > > > > > > > > > grid.*
> > > > > > > > > > > > > > > > I think, we should make a test suite, that
> will test the old
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > > until we
> > > > > > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > > > > I don't see any point in having a single
> class with "*flags"*
> > > > > > > > > > > >
> > > > > > > > > > > > field,
> > > > > > > > > > > > > > that
> > > > > > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > > > > > Usage of *deploy(), markDeploy(...),
> undeploy(),
> > > > > > > > > > >
> > > > > > > > > > > markUndeploy(...)*
> > > > > > > > > > > > > > looks
> > > > > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > > > > Why not have a separate message type for
> each action instead?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > > > > > *ServicesDeploymentManager*,
> *ServicesDeploymentTask *and all
> > > > > > > > > > >
> > > > > > > > > > > other
> > > > > > > > > > > > > > classes
> > > > > > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > > > > > I think, they would look better if we use a
> singular word
> > > > > > > > > > >
> > > > > > > > > > > *Service
> > > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServicesDeploymentManager ->
> ServiceDeploymentManager*
> > > > > > > > > > > > > > > > *ServicesDeploymentActions ->
> ServiceDeploymentActions*
> > > > > > > > > > > > > > > > *ServicesDeploymentTask ->
> ServiceDeploymentTask*
> > > > > > > > > > > > > > > > *ServicesCommonDiscoveryData ->
> ServiceCommonDiscoveryData*
> > > > > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > > > > >
> > > > > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage ->
> ServiceDeploymentResponse*
> > > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > > > > >
> > > > > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > > > > >
> > > > > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > > > > *ServiceFullDeploymentsResults ->
> ServiceFullDeploymentResult*
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Let's do this as the final step of the code
> review to avoid
> > > > > > > > > > > >
> > > > > > > > > > > > repeated
> > > > > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov
> <
> > > > > > > > > > > >
> > > > > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I don't see any problem in letting
> services work on a
> > > > > > > > > > >
> > > > > > > > > > > deactivated
> > > > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > > > All services need is discovery messages
> and compute tasks.
> > > > > > > > > > > > > > > > > Both of these features are available at
> all times.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But it should be configurable. Services
> may need caches for
> > > > > > > > > > >
> > > > > > > > > > > their
> > > > > > > > > > > > > > work,
> > > > > > > > > > > > > > > > > so it's better to undeploy such services
> on cluster
> > > > > > > > > > >
> > > > > > > > > > > deactivation.
> > > > > > > > > > > > > > > > > We may introduce a new property in
> ServiceConfiguration.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think, this topic deserves a separate
> discussion.
> > > > > > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey
> Kuznetsov <
> > > > > > > > > > > >
> > > > > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'm thinking about to use Services API
> to implement Web Agent
> > > > > > > > > > > >
> > > > > > > > > > > > as a
> > > > > > > > > > > > > > cluster
> > > > > > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > > > > > It will improve Web Console UX, because
> it will not needed to
> > > > > > > > > > > >
> > > > > > > > > > > > start
> > > > > > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > > > > > Just start cluster with Web agent
> enabled on cluster
> > > > > > > > > > > >
> > > > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But in order to do this, I need that
> services should:
> > > > > > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > > > > >   2) Auto restart with cluster (when
> cluster was restarted).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Could we support mentioned features on
> "Service Grid
> > > > > > > > > > >
> > > > > > > > > > > redesign -
> > > > > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > 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.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
The wiki's article [1] has been updated according to the merged solution [2].

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
[2] https://issues.apache.org/jira/browse/IGNITE-9607

On Fri, Dec 28, 2018 at 1:10 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Igniters,
>
> to have an opportunity to test both new and old service grid
> implementations, we added new config-plans on TC:
> - Service Grid [1] - runs tests in new (default) mode
> - Service Grid (legacy mode) [2] - runs tests in old (legacy) mode
>
> Both plans contain the following test-suites:
> - IgniteServiceGridTestSuite (newly added suite)
> - IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic 2")
>
> Also, the plans have been included in RunAll.
>
> [1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid
> [2] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode
>
> On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov <ni...@apache.org> wrote:
> >
> > Hello, Igniters.
> >
> > I've merged Service Grid Redesign - Phase 1 to the master.
> > Vyacheslav, great contribution!
> >
> > Thanks for all Ignite veterans both for the code and design review.
> >
> > В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> > > Hello, Igniters.
> > >
> > > Please, let us know, if someone want to do additional review of this PR.
> > >
> > > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > > > Igniters, especially future reviewers,
> > > >
> > > > Discovery listener registered by 'IgniteServiceProcessor' become
> > > > implemented 'HighPriorityListener', seems it's best lock-free
> > > > solutions discussed during the review. This change is covered by
> > > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should
> > > > protect us if the order of listeners will be changed.
> > > >
> > > > It's about the problem of custom messages which are nullified by PME
> > > > [1] and are listened by service deployment to manage the lifecycle of
> > > > affinity services. This guarantees that service deployment discovery
> > > > listener will be notified earlier than PME's discovery listener and
> > > > will be able to capture custom messages which may be nullified in PME
> > > > process.
> > > >
> > > > Looks like we do not have any controversial questions now.
> > > >
> > > > Thanks!
> > > >
> > > > [1] http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > > >
> > > >
> > > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > >
> > > > > Stanislav, thank you for the notes, most of them have been resolved. I
> > > > > answered on GitHub.
> > > > >
> > > > >
> > > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > > > <st...@gmail.com> wrote:
> > > > > >
> > > > > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> > > > > > I’ve left some comments – almost all are about minor issues, grammar and code style.
> > > > > >
> > > > > > Stan
> > > > > >
> > > > > > From: Vyacheslav Daradur
> > > > > > Sent: 21 декабря 2018 г. 14:58
> > > > > > To: dev@ignite.apache.org
> > > > > > Subject: Re: Service grid redesign
> > > > > >
> > > > > > Igniters,
> > > > > >
> > > > > > Please, let us know if someone is going to do an additional review?
> > > > > >
> > > > > > We should know can we merge the PR since it has been approved by
> > > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> > > > > > community members.
> > > > > >
> > > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > > >
> > > > > > > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> > > > > > >
> > > > > > > See the following names (Actual name <- Previously used):
> > > > > > >
> > > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > > >
> > > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > > >
> > > > > > > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > > > > > > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> > > > > > >
> > > > > > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > > > > > > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> > > > > > >
> > > > > > > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > > > > > > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> > > > > > >
> > > > > > > Also, I had a short talk with Alexey Goncharuk about the problem of
> > > > > > > nullified custom messages. I changed the implementation to a lock-free
> > > > > > > solution which allows us to nullify messages depend on an using
> > > > > > > counter.
> > > > > > >
> > > > > > > In comparison with high priority listener, this allows us to not copy
> > > > > > > custom discovery event in service deployment manager and work with the
> > > > > > > original object.
> > > > > > >
> > > > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > > > > > > >
> > > > > > > > Denis, great news!
> > > > > > > >
> > > > > > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > I finished my code review. The pool request looks good to me.
> > > > > > > > >
> > > > > > > > > Does anybody else want to look at the changes?
> > > > > > > > > There are a few points, that we didn't meet an agreement on,
> > > > > > > > > though they don't affect the behaviour in any way:
> > > > > > > > >
> > > > > > > > >    - *Class naming. * See the discussion above.
> > > > > > > > >    - *Unnecessary task object cleaning. *
> > > > > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > > > > > > >    and it should be removed.
> > > > > > > > >    By the moment, when this method is called, the task object is removed
> > > > > > > > >    from all collections anyway, so it's ready for garbage collection.
> > > > > > > > >    Removing data from it doesn't help anybody.
> > > > > > > > >    -
> > > > > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > > > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > > > > > > >    I don't see any point in testing an interface implementation, that only
> > > > > > > > >    saves some objects and returns them from certain methods.
> > > > > > > > >    - Interface for events with servicesDeploymentActions() method.
> > > > > > > > >    Take a look at the discussion:
> > > > > > > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > > >
> > > > > > > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > > > clumsy to me.
> > > > > > > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > > > > > > be solved
> > > > > > > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > > > > > > >
> > > > > > > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > > > > > > synchronized and
> > > > > > > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > > > > > > the event object.
> > > > > > > > > But this solution is the same, it's just a matter of taste.
> > > > > > > > >
> > > > > > > > > If anybody wants to look the the code of the PR, please consider these
> > > > > > > > > points as well.
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > I don't think that differences with your and my naming is huge :)
> > > > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > > >
> > > > > > > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > > > > > > >
> > > > > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > > >
> > > > > > > > > > > "Service"
> > > > > > > > > > >
> > > > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > > >
> > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > >
> > > > > > > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Slava,
> > > > > > > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > > > > > > >
> > > > > > > > > > > > Nik,
> > > > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > > > > "Service",
> > > > > > > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > > > > > > >
> > > > > > > > > > > "Services"
> > > > > > > > > > > > for some reason.
> > > > > > > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > > > > > > I think, we should unify these names.
> > > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > > >
> > > > > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > > > > > > >
> > > > > > > > > > mark
> > > > > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > > >
> > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > > > I think all tests in the package:
> > > > > > > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > > > > > > included in RunAll.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > > > > > > I changed to the following structure:
> > > > > > > > > > > > >
> > > > > > > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > > > > }
> > > > > > > > > > > > >
> > > > > > > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > > > > > > >
> > > > > > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > >
> > > > > > > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > > > > > > manages several services, not single.
> > > > > > > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > > > > > > >
> > > > > > > > > > with
> > > > > > > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > >
> > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > > > name.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > > >
> > > > > > > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > > > > > > >
> > > > > > > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > > > > > > >
> > > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Great news.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > > >
> > > > > > > > > > grid.*
> > > > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > > >
> > > > > > > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > > >
> > > > > > > > > > other
> > > > > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > > >
> > > > > > > > > > *Service
> > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > > > > > > >
> > > > > > > > > > > > > content for reader.
> > > > > > > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Same for deployment - if this message will initiate single
> > > > > > > > > >
> > > > > > > > > > deployment
> > > > > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > > > > > > >
> > > > > > > > > > weeks.
> > > > > > > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > > > > > > >
> > > > > > > > > > > to
> > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > > >
> > > > > > > > > > grid.*
> > > > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > > >
> > > > > > > > > > > > > implementation
> > > > > > > > > > > > > > > until we
> > > > > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > > > > > > >
> > > > > > > > > > > field,
> > > > > > > > > > > > > that
> > > > > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > > > > > > >
> > > > > > > > > > markUndeploy(...)*
> > > > > > > > > > > > > looks
> > > > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > > >
> > > > > > > > > > other
> > > > > > > > > > > > > classes
> > > > > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > > >
> > > > > > > > > > *Service
> > > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > > > >
> > > > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > > >
> > > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > > > >
> > > > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > > > >
> > > > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > > > > > > >
> > > > > > > > > > > repeated
> > > > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > > > > > > >
> > > > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I don't see any problem in letting services work on a
> > > > > > > > > >
> > > > > > > > > > deactivated
> > > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > > > > > > >
> > > > > > > > > > their
> > > > > > > > > > > > > work,
> > > > > > > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > > > > > > >
> > > > > > > > > > deactivation.
> > > > > > > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > > > > > > >
> > > > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > > > > > > >
> > > > > > > > > > > as a
> > > > > > > > > > > > > cluster
> > > > > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > > > > > > >
> > > > > > > > > > > start
> > > > > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > > > > > > >
> > > > > > > > > > > configuration.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > > > > > > >
> > > > > > > > > > redesign -
> > > > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 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.



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Igniters,

to have an opportunity to test both new and old service grid
implementations, we added new config-plans on TC:
- Service Grid [1] - runs tests in new (default) mode
- Service Grid (legacy mode) [2] - runs tests in old (legacy) mode

Both plans contain the following test-suites:
- IgniteServiceGridTestSuite (newly added suite)
- IgniteServiceConfigVariationsFullApiTestSuite (was moved from "Basic 2")

Also, the plans have been included in RunAll.

[1] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGrid
[2] https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ServiceGridLegacyMode

On Thu, Dec 27, 2018 at 6:24 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> Hello, Igniters.
>
> I've merged Service Grid Redesign - Phase 1 to the master.
> Vyacheslav, great contribution!
>
> Thanks for all Ignite veterans both for the code and design review.
>
> В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> > Hello, Igniters.
> >
> > Please, let us know, if someone want to do additional review of this PR.
> >
> > В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > > Igniters, especially future reviewers,
> > >
> > > Discovery listener registered by 'IgniteServiceProcessor' become
> > > implemented 'HighPriorityListener', seems it's best lock-free
> > > solutions discussed during the review. This change is covered by
> > > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should
> > > protect us if the order of listeners will be changed.
> > >
> > > It's about the problem of custom messages which are nullified by PME
> > > [1] and are listened by service deployment to manage the lifecycle of
> > > affinity services. This guarantees that service deployment discovery
> > > listener will be notified earlier than PME's discovery listener and
> > > will be able to capture custom messages which may be nullified in PME
> > > process.
> > >
> > > Looks like we do not have any controversial questions now.
> > >
> > > Thanks!
> > >
> > > [1] http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > >
> > >
> > > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > >
> > > > Stanislav, thank you for the notes, most of them have been resolved. I
> > > > answered on GitHub.
> > > >
> > > >
> > > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > > <st...@gmail.com> wrote:
> > > > >
> > > > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> > > > > I’ve left some comments – almost all are about minor issues, grammar and code style.
> > > > >
> > > > > Stan
> > > > >
> > > > > From: Vyacheslav Daradur
> > > > > Sent: 21 декабря 2018 г. 14:58
> > > > > To: dev@ignite.apache.org
> > > > > Subject: Re: Service grid redesign
> > > > >
> > > > > Igniters,
> > > > >
> > > > > Please, let us know if someone is going to do an additional review?
> > > > >
> > > > > We should know can we merge the PR since it has been approved by
> > > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> > > > > community members.
> > > > >
> > > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > >
> > > > > > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> > > > > >
> > > > > > See the following names (Actual name <- Previously used):
> > > > > >
> > > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > >
> > > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > >
> > > > > > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > > > > > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> > > > > >
> > > > > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > > > > > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> > > > > >
> > > > > > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > > > > > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> > > > > >
> > > > > > Also, I had a short talk with Alexey Goncharuk about the problem of
> > > > > > nullified custom messages. I changed the implementation to a lock-free
> > > > > > solution which allows us to nullify messages depend on an using
> > > > > > counter.
> > > > > >
> > > > > > In comparison with high priority listener, this allows us to not copy
> > > > > > custom discovery event in service deployment manager and work with the
> > > > > > original object.
> > > > > >
> > > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > > > > > >
> > > > > > > Denis, great news!
> > > > > > >
> > > > > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > I finished my code review. The pool request looks good to me.
> > > > > > > >
> > > > > > > > Does anybody else want to look at the changes?
> > > > > > > > There are a few points, that we didn't meet an agreement on,
> > > > > > > > though they don't affect the behaviour in any way:
> > > > > > > >
> > > > > > > >    - *Class naming. * See the discussion above.
> > > > > > > >    - *Unnecessary task object cleaning. *
> > > > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > > > > > >    and it should be removed.
> > > > > > > >    By the moment, when this method is called, the task object is removed
> > > > > > > >    from all collections anyway, so it's ready for garbage collection.
> > > > > > > >    Removing data from it doesn't help anybody.
> > > > > > > >    -
> > > > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > > > > > >    I don't see any point in testing an interface implementation, that only
> > > > > > > >    saves some objects and returns them from certain methods.
> > > > > > > >    - Interface for events with servicesDeploymentActions() method.
> > > > > > > >    Take a look at the discussion:
> > > > > > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > >
> > > > > > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > > clumsy to me.
> > > > > > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > > > > > be solved
> > > > > > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > > > > > >
> > > > > > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > > > > > synchronized and
> > > > > > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > > > > > the event object.
> > > > > > > > But this solution is the same, it's just a matter of taste.
> > > > > > > >
> > > > > > > > If anybody wants to look the the code of the PR, please consider these
> > > > > > > > points as well.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > > > > > >
> > > > > > > > > Denis,
> > > > > > > > >
> > > > > > > > > I don't think that differences with your and my naming is huge :)
> > > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > >
> > > > > > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > > > > > >
> > > > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > >
> > > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > >
> > > > > > > > > > "Service"
> > > > > > > > > >
> > > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > >
> > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > >
> > > > > > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Slava,
> > > > > > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > > > > > >
> > > > > > > > > > > Nik,
> > > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > > > "Service",
> > > > > > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > > > > > >
> > > > > > > > > > "Services"
> > > > > > > > > > > for some reason.
> > > > > > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > > > > > I think, we should unify these names.
> > > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > >
> > > > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > > > > > >
> > > > > > > > > mark
> > > > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > > > >
> > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > >
> > > > > > > > > > > > implementation
> > > > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > > >
> > > > > > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > > I think all tests in the package:
> > > > > > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > > > > > included in RunAll.
> > > > > > > > > > > >
> > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > >
> > > > > > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > > > > > I changed to the following structure:
> > > > > > > > > > > >
> > > > > > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > > > }
> > > > > > > > > > > >
> > > > > > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > > > > > >
> > > > > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > > > > >
> > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > >
> > > > > > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > > > > > manages several services, not single.
> > > > > > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > > > > > >
> > > > > > > > > with
> > > > > > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > > > > > >
> > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > >
> > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > > name.
> > > > > > > > > > > >
> > > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > >
> > > > > > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > > > > > >
> > > > > > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > > > > > >
> > > > > > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > > > > > >
> > > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Great news.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > >
> > > > > > > > > grid.*
> > > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > >
> > > > > > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > > >
> > > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > >
> > > > > > > > > other
> > > > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > >
> > > > > > > > > *Service
> > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > > > > > >
> > > > > > > > > > > > content for reader.
> > > > > > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Same for deployment - if this message will initiate single
> > > > > > > > >
> > > > > > > > > deployment
> > > > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > >
> > > > > > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > > > > > >
> > > > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > > > > > >
> > > > > > > > > weeks.
> > > > > > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > > > > > >
> > > > > > > > > > to
> > > > > > > > > > > > avoid
> > > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > >
> > > > > > > > > grid.*
> > > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > >
> > > > > > > > > > > > implementation
> > > > > > > > > > > > > > until we
> > > > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > > > > > >
> > > > > > > > > > field,
> > > > > > > > > > > > that
> > > > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > > > > > >
> > > > > > > > > markUndeploy(...)*
> > > > > > > > > > > > looks
> > > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > >
> > > > > > > > > other
> > > > > > > > > > > > classes
> > > > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > >
> > > > > > > > > *Service
> > > > > > > > > > > > *instead.
> > > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > > >
> > > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > >
> > > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > > >
> > > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > > >
> > > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > > > > > >
> > > > > > > > > > repeated
> > > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > > > > > >
> > > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I don't see any problem in letting services work on a
> > > > > > > > >
> > > > > > > > > deactivated
> > > > > > > > > > > > cluster.
> > > > > > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > > > > > >
> > > > > > > > > their
> > > > > > > > > > > > work,
> > > > > > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > > > > > >
> > > > > > > > > deactivation.
> > > > > > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > > > > > >
> > > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > > :
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > > > > > >
> > > > > > > > > > as a
> > > > > > > > > > > > cluster
> > > > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > > > > > >
> > > > > > > > > > start
> > > > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > > > > > >
> > > > > > > > > > configuration.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > > > > > >
> > > > > > > > > redesign -
> > > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > 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.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Igniters.

I've merged Service Grid Redesign - Phase 1 to the master.
Vyacheslav, great contribution!

Thanks for all Ignite veterans both for the code and design review.

В Пн, 24/12/2018 в 20:50 +0300, Nikolay Izhikov пишет:
> Hello, Igniters.
> 
> Please, let us know, if someone want to do additional review of this PR.
> 
> В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> > Igniters, especially future reviewers,
> > 
> > Discovery listener registered by 'IgniteServiceProcessor' become
> > implemented 'HighPriorityListener', seems it's best lock-free
> > solutions discussed during the review. This change is covered by
> > `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should
> > protect us if the order of listeners will be changed.
> > 
> > It's about the problem of custom messages which are nullified by PME
> > [1] and are listened by service deployment to manage the lifecycle of
> > affinity services. This guarantees that service deployment discovery
> > listener will be notified earlier than PME's discovery listener and
> > will be able to capture custom messages which may be nullified in PME
> > process.
> > 
> > Looks like we do not have any controversial questions now.
> > 
> > Thanks!
> > 
> > [1] http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> > 
> > 
> > On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > 
> > > Stanislav, thank you for the notes, most of them have been resolved. I
> > > answered on GitHub.
> > > 
> > > 
> > > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > > <st...@gmail.com> wrote:
> > > > 
> > > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> > > > I’ve left some comments – almost all are about minor issues, grammar and code style.
> > > > 
> > > > Stan
> > > > 
> > > > From: Vyacheslav Daradur
> > > > Sent: 21 декабря 2018 г. 14:58
> > > > To: dev@ignite.apache.org
> > > > Subject: Re: Service grid redesign
> > > > 
> > > > Igniters,
> > > > 
> > > > Please, let us know if someone is going to do an additional review?
> > > > 
> > > > We should know can we merge the PR since it has been approved by
> > > > Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> > > > community members.
> > > > 
> > > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > > 
> > > > > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> > > > > 
> > > > > See the following names (Actual name <- Previously used):
> > > > > 
> > > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > > 
> > > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > > 
> > > > > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > > > > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> > > > > 
> > > > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > > > > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> > > > > 
> > > > > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > > > > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> > > > > 
> > > > > Also, I had a short talk with Alexey Goncharuk about the problem of
> > > > > nullified custom messages. I changed the implementation to a lock-free
> > > > > solution which allows us to nullify messages depend on an using
> > > > > counter.
> > > > > 
> > > > > In comparison with high priority listener, this allows us to not copy
> > > > > custom discovery event in service deployment manager and work with the
> > > > > original object.
> > > > > 
> > > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > > > > > 
> > > > > > Denis, great news!
> > > > > > 
> > > > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > > Guys,
> > > > > > > 
> > > > > > > I finished my code review. The pool request looks good to me.
> > > > > > > 
> > > > > > > Does anybody else want to look at the changes?
> > > > > > > There are a few points, that we didn't meet an agreement on,
> > > > > > > though they don't affect the behaviour in any way:
> > > > > > > 
> > > > > > >    - *Class naming. * See the discussion above.
> > > > > > >    - *Unnecessary task object cleaning. *
> > > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > > > > >    and it should be removed.
> > > > > > >    By the moment, when this method is called, the task object is removed
> > > > > > >    from all collections anyway, so it's ready for garbage collection.
> > > > > > >    Removing data from it doesn't help anybody.
> > > > > > >    -
> > > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > > > > >    I don't see any point in testing an interface implementation, that only
> > > > > > >    saves some objects and returns them from certain methods.
> > > > > > >    - Interface for events with servicesDeploymentActions() method.
> > > > > > >    Take a look at the discussion:
> > > > > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > > 
> > > > > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > > clumsy to me.
> > > > > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > > > > be solved
> > > > > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > > > > > 
> > > > > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > > > > synchronized and
> > > > > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > > > > the event object.
> > > > > > > But this solution is the same, it's just a matter of taste.
> > > > > > > 
> > > > > > > If anybody wants to look the the code of the PR, please consider these
> > > > > > > points as well.
> > > > > > > 
> > > > > > > Denis
> > > > > > > 
> > > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > > > > > 
> > > > > > > > Denis,
> > > > > > > > 
> > > > > > > > I don't think that differences with your and my naming is huge :)
> > > > > > > > And, it's definetely a matter of taste.
> > > > > > > > 
> > > > > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > > > > > 
> > > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > 
> > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > 
> > > > > > > > > "Service"
> > > > > > > > > 
> > > > > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > > 
> > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > 
> > > > > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > > 
> > > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > Slava,
> > > > > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > > > > > 
> > > > > > > > > > Nik,
> > > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > > "Service",
> > > > > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > > > > > 
> > > > > > > > > "Services"
> > > > > > > > > > for some reason.
> > > > > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > > > > I think, we should unify these names.
> > > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > > 
> > > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > > > > > 
> > > > > > > > mark
> > > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > > 
> > > > > > > > > > Denis
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > > > 
> > > > > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > 
> > > > > > > > > > > implementation
> > > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > > 
> > > > > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > > I think all tests in the package:
> > > > > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > > > > included in RunAll.
> > > > > > > > > > > 
> > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > 
> > > > > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > > > > I changed to the following structure:
> > > > > > > > > > > 
> > > > > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > > }
> > > > > > > > > > > 
> > > > > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > > }
> > > > > > > > > > > 
> > > > > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > > > > > 
> > > > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > > > > 
> > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > 
> > > > > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > > > > manages several services, not single.
> > > > > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > > > > > 
> > > > > > > > with
> > > > > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > > > > > 
> > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > 
> > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > > > > name.
> > > > > > > > > > > 
> > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > 
> > > > > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > > > > > 
> > > > > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > > > > > 
> > > > > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > > > > > 
> > > > > > > > nizhikov@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > > 
> > > > > > > > > > > > Great news.
> > > > > > > > > > > > 
> > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > 
> > > > > > > > grid.*
> > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > 
> > > > > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > > > > > 
> > > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > > 
> > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > 
> > > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > > 
> > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > 
> > > > > > > > other
> > > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > 
> > > > > > > > *Service
> > > > > > > > > > > *instead.
> > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > 
> > > > > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > > > > > 
> > > > > > > > > > > content for reader.
> > > > > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > > > > > 
> > > > > > > > > > > > Same for deployment - if this message will initiate single
> > > > > > > > 
> > > > > > > > deployment
> > > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > > 
> > > > > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > > > > > 
> > > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > > > > > 
> > > > > > > > weeks.
> > > > > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > > > > > 
> > > > > > > > > to
> > > > > > > > > > > avoid
> > > > > > > > > > > > > controversy.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > > 
> > > > > > > > grid.*
> > > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > > 
> > > > > > > > > > > implementation
> > > > > > > > > > > > > until we
> > > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > > > > > 
> > > > > > > > > field,
> > > > > > > > > > > that
> > > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > > > > > 
> > > > > > > > markUndeploy(...)*
> > > > > > > > > > > looks
> > > > > > > > > > > > > wrong.
> > > > > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > > 
> > > > > > > > other
> > > > > > > > > > > classes
> > > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > > 
> > > > > > > > *Service
> > > > > > > > > > > *instead.
> > > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > > 
> > > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > > 
> > > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > > 
> > > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > > 
> > > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > > 
> > > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > > > > > 
> > > > > > > > > repeated
> > > > > > > > > > > > > renaming.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > > 
> > > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > > > > > 
> > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I don't see any problem in letting services work on a
> > > > > > > > 
> > > > > > > > deactivated
> > > > > > > > > > > cluster.
> > > > > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > > > > > 
> > > > > > > > their
> > > > > > > > > > > work,
> > > > > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > > > > > 
> > > > > > > > deactivation.
> > > > > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > > > > > 
> > > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > > :
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > > > > > 
> > > > > > > > > as a
> > > > > > > > > > > cluster
> > > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > > > > > 
> > > > > > > > > start
> > > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > > > > > 
> > > > > > > > > configuration.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > > > > > 
> > > > > > > > redesign -
> > > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > > 
> > > 
> > > 
> > > --
> > > Best Regards, Vyacheslav D.
> > 
> > 
> > 
> > --
> > Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Igniters.

Please, let us know, if someone want to do additional review of this PR.

В Пн, 24/12/2018 в 20:23 +0300, Vyacheslav Daradur пишет:
> Igniters, especially future reviewers,
> 
> Discovery listener registered by 'IgniteServiceProcessor' become
> implemented 'HighPriorityListener', seems it's best lock-free
> solutions discussed during the review. This change is covered by
> `ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should
> protect us if the order of listeners will be changed.
> 
> It's about the problem of custom messages which are nullified by PME
> [1] and are listened by service deployment to manage the lifecycle of
> affinity services. This guarantees that service deployment discovery
> listener will be notified earlier than PME's discovery listener and
> will be able to capture custom messages which may be nullified in PME
> process.
> 
> Looks like we do not have any controversial questions now.
> 
> Thanks!
> 
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html
> 
> 
> On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > 
> > Stanislav, thank you for the notes, most of them have been resolved. I
> > answered on GitHub.
> > 
> > 
> > On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> > <st...@gmail.com> wrote:
> > > 
> > > I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> > > I’ve left some comments – almost all are about minor issues, grammar and code style.
> > > 
> > > Stan
> > > 
> > > From: Vyacheslav Daradur
> > > Sent: 21 декабря 2018 г. 14:58
> > > To: dev@ignite.apache.org
> > > Subject: Re: Service grid redesign
> > > 
> > > Igniters,
> > > 
> > > Please, let us know if someone is going to do an additional review?
> > > 
> > > We should know can we merge the PR since it has been approved by
> > > Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> > > community members.
> > > 
> > > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > > > 
> > > > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> > > > 
> > > > See the following names (Actual name <- Previously used):
> > > > 
> > > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > > > 
> > > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > > > 
> > > > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > > > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> > > > 
> > > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > > > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> > > > 
> > > > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > > > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> > > > 
> > > > Also, I had a short talk with Alexey Goncharuk about the problem of
> > > > nullified custom messages. I changed the implementation to a lock-free
> > > > solution which allows us to nullify messages depend on an using
> > > > counter.
> > > > 
> > > > In comparison with high priority listener, this allows us to not copy
> > > > custom discovery event in service deployment manager and work with the
> > > > original object.
> > > > 
> > > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > > > > 
> > > > > Denis, great news!
> > > > > 
> > > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > > > 
> > > > > 
> > > > > 
> > > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > > Guys,
> > > > > > 
> > > > > > I finished my code review. The pool request looks good to me.
> > > > > > 
> > > > > > Does anybody else want to look at the changes?
> > > > > > There are a few points, that we didn't meet an agreement on,
> > > > > > though they don't affect the behaviour in any way:
> > > > > > 
> > > > > >    - *Class naming. * See the discussion above.
> > > > > >    - *Unnecessary task object cleaning. *
> > > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > > > >    and it should be removed.
> > > > > >    By the moment, when this method is called, the task object is removed
> > > > > >    from all collections anyway, so it's ready for garbage collection.
> > > > > >    Removing data from it doesn't help anybody.
> > > > > >    -
> > > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > > > >    I don't see any point in testing an interface implementation, that only
> > > > > >    saves some objects and returns them from certain methods.
> > > > > >    - Interface for events with servicesDeploymentActions() method.
> > > > > >    Take a look at the discussion:
> > > > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > > > 
> > > > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > > clumsy to me.
> > > > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > > > be solved
> > > > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > > > > 
> > > > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > > > synchronized and
> > > > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > > > the event object.
> > > > > > But this solution is the same, it's just a matter of taste.
> > > > > > 
> > > > > > If anybody wants to look the the code of the PR, please consider these
> > > > > > points as well.
> > > > > > 
> > > > > > Denis
> > > > > > 
> > > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > > > > 
> > > > > > > Denis,
> > > > > > > 
> > > > > > > I don't think that differences with your and my naming is huge :)
> > > > > > > And, it's definetely a matter of taste.
> > > > > > > 
> > > > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > > > > 
> > > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > 
> > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > 
> > > > > > > > "Service"
> > > > > > > > 
> > > > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > > > 'IgniteServicesProcessor'?
> > > > > > > > 
> > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > 
> > > > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > > > 
> > > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > Slava,
> > > > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > > > > 
> > > > > > > > > Nik,
> > > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > > "Service",
> > > > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > > > > 
> > > > > > > > "Services"
> > > > > > > > > for some reason.
> > > > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > > > I think, we should unify these names.
> > > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > > > 
> > > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > > > > 
> > > > > > > mark
> > > > > > > > > the point in time, when deployment is finished.
> > > > > > > > > 
> > > > > > > > > Denis
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > > > 
> > > > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > 
> > > > > > > > > > implementation
> > > > > > > > > > > until we remove it from the project.
> > > > > > > > > > 
> > > > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > > > phase 1 will be merged.
> > > > > > > > > > I think all tests in the package:
> > > > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > > > included in RunAll.
> > > > > > > > > > 
> > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > 
> > > > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > > > I changed to the following structure:
> > > > > > > > > > 
> > > > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > > > > 
> > > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > > > 
> > > > > > > > > > > *3. Naming.*
> > > > > > > > > > 
> > > > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > > > manages several services, not single.
> > > > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > > > > 
> > > > > > > with
> > > > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > > > > 
> > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > 
> > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > > > name.
> > > > > > > > > > 
> > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > 
> > > > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > > > > 
> > > > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > > > > 
> > > > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > > > > 
> > > > > > > nizhikov@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > Hello, Denis.
> > > > > > > > > > > 
> > > > > > > > > > > Great news.
> > > > > > > > > > > 
> > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > 
> > > > > > > grid.*
> > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > 
> > > > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > > > > 
> > > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > > > 
> > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > 
> > > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > > > 
> > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > 
> > > > > > > other
> > > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > 
> > > > > > > *Service
> > > > > > > > > > *instead.
> > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > 
> > > > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > > > > 
> > > > > > > > > > content for reader.
> > > > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > > > > 
> > > > > > > > > > > Same for deployment - if this message will initiate single
> > > > > > > 
> > > > > > > deployment
> > > > > > > > > > process then it should use deployment.
> > > > > > > > > > > otherwise - deployments.
> > > > > > > > > > > 
> > > > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > > > > 
> > > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > > Guys,
> > > > > > > > > > > > 
> > > > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > > > > 
> > > > > > > weeks.
> > > > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > > > > 
> > > > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > > > > 
> > > > > > > > to
> > > > > > > > > > avoid
> > > > > > > > > > > > controversy.
> > > > > > > > > > > > 
> > > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > > > 
> > > > > > > grid.*
> > > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > > > 
> > > > > > > > > > implementation
> > > > > > > > > > > > until we
> > > > > > > > > > > > remove it from the project.
> > > > > > > > > > > > 
> > > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > > > > 
> > > > > > > > field,
> > > > > > > > > > that
> > > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > > > > 
> > > > > > > markUndeploy(...)*
> > > > > > > > > > looks
> > > > > > > > > > > > wrong.
> > > > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > > > > 
> > > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > > > 
> > > > > > > other
> > > > > > > > > > classes
> > > > > > > > > > > > with Services word in them.
> > > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > > > 
> > > > > > > *Service
> > > > > > > > > > *instead.
> > > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > > I propose the following class names:
> > > > > > > > > > > > 
> > > > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > > > 
> > > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > > > 
> > > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > > > 
> > > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > > > 
> > > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > > > 
> > > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > > > 
> > > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > > > > 
> > > > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > > > > 
> > > > > > > > repeated
> > > > > > > > > > > > renaming.
> > > > > > > > > > > > 
> > > > > > > > > > > > Denis
> > > > > > > > > > > > 
> > > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > > > > 
> > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > > 
> > > > > > > > > > > > > Alexey,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I don't see any problem in letting services work on a
> > > > > > > 
> > > > > > > deactivated
> > > > > > > > > > cluster.
> > > > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > > > > 
> > > > > > > their
> > > > > > > > > > work,
> > > > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > > > > 
> > > > > > > deactivation.
> > > > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > > 
> > > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > > > > 
> > > > > > > > akuznetsov@apache.org
> > > > > > > > > > > :
> > > > > > > > > > > > > 
> > > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > > > > 
> > > > > > > > as a
> > > > > > > > > > cluster
> > > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > > > > 
> > > > > > > > start
> > > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > > > > 
> > > > > > > > configuration.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > > > > 
> > > > > > > redesign -
> > > > > > > > > > phase 2" ?
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > 
> > > > 
> > > > 
> > > > 
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > 
> > > 
> > > 
> > > --
> > > Best Regards, Vyacheslav D.
> > > 
> > 
> > 
> > --
> > Best Regards, Vyacheslav D.
> 
> 
> 
> --
> Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Igniters, especially future reviewers,

Discovery listener registered by 'IgniteServiceProcessor' become
implemented 'HighPriorityListener', seems it's best lock-free
solutions discussed during the review. This change is covered by
`ServiceDeploymentDiscoveryListenerNotificationOrderTest` which should
protect us if the order of listeners will be changed.

It's about the problem of custom messages which are nullified by PME
[1] and are listened by service deployment to manage the lifecycle of
affinity services. This guarantees that service deployment discovery
listener will be notified earlier than PME's discovery listener and
will be able to capture custom messages which may be nullified in PME
process.

Looks like we do not have any controversial questions now.

Thanks!

[1] http://apache-ignite-developers.2346864.n4.nabble.com/Danger-change-of-DiscoveryCustomEvent-in-GridDhtPartitionsExchangeFuture-onDone-td35946.html


On Mon, Dec 24, 2018 at 4:23 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Stanislav, thank you for the notes, most of them have been resolved. I
> answered on GitHub.
>
>
> On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
> <st...@gmail.com> wrote:
> >
> > I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> > I’ve left some comments – almost all are about minor issues, grammar and code style.
> >
> > Stan
> >
> > From: Vyacheslav Daradur
> > Sent: 21 декабря 2018 г. 14:58
> > To: dev@ignite.apache.org
> > Subject: Re: Service grid redesign
> >
> > Igniters,
> >
> > Please, let us know if someone is going to do an additional review?
> >
> > We should know can we merge the PR since it has been approved by
> > Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> > community members.
> >
> > On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> > >
> > > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> > >
> > > See the following names (Actual name <- Previously used):
> > >
> > > - ServiceDeploymentManager <- ServicesDeploymentManager
> > > - ServiceDeploymentActions <- ServicesDeploymentActions
> > > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > > - ServiceDeploymentTask <- ServicesDeploymentTask
> > >
> > > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> > >
> > > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> > >
> > > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> > >
> > > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> > >
> > > Also, I had a short talk with Alexey Goncharuk about the problem of
> > > nullified custom messages. I changed the implementation to a lock-free
> > > solution which allows us to nullify messages depend on an using
> > > counter.
> > >
> > > In comparison with high priority listener, this allows us to not copy
> > > custom discovery event in service deployment manager and work with the
> > > original object.
> > >
> > > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > > >
> > > > Denis, great news!
> > > >
> > > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > > >
> > > >
> > > >
> > > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > > Guys,
> > > > >
> > > > > I finished my code review. The pool request looks good to me.
> > > > >
> > > > > Does anybody else want to look at the changes?
> > > > > There are a few points, that we didn't meet an agreement on,
> > > > > though they don't affect the behaviour in any way:
> > > > >
> > > > >    - *Class naming. * See the discussion above.
> > > > >    - *Unnecessary task object cleaning. *
> > > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > > >    and it should be removed.
> > > > >    By the moment, when this method is called, the task object is removed
> > > > >    from all collections anyway, so it's ready for garbage collection.
> > > > >    Removing data from it doesn't help anybody.
> > > > >    -
> > > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > > >    I don't see any point in testing an interface implementation, that only
> > > > >    saves some objects and returns them from certain methods.
> > > > >    - Interface for events with servicesDeploymentActions() method.
> > > > >    Take a look at the discussion:
> > > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > > >
> > > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > > clumsy to me.
> > > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > > be solved
> > > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > > >
> > > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > > synchronized and
> > > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > > the event object.
> > > > > But this solution is the same, it's just a matter of taste.
> > > > >
> > > > > If anybody wants to look the the code of the PR, please consider these
> > > > > points as well.
> > > > >
> > > > > Denis
> > > > >
> > > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > I don't think that differences with your and my naming is huge :)
> > > > > > And, it's definetely a matter of taste.
> > > > > >
> > > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > > >
> > > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > > >
> > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > >
> > > > > > > "Service"
> > > > > > >
> > > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > > 'IgniteServicesProcessor'?
> > > > > > >
> > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > "Single deployments" doesn't sound right.
> > > > > > >
> > > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > > >
> > > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Slava,
> > > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > > >
> > > > > > > > Nik,
> > > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > > "Service",
> > > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > > >
> > > > > > > "Services"
> > > > > > > > for some reason.
> > > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > > I think, we should unify these names.
> > > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > > "Single deployments" doesn't sound right.
> > > > > > > >
> > > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > > >
> > > > > > mark
> > > > > > > > the point in time, when deployment is finished.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > >
> > > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > > >
> > > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > >
> > > > > > > > > implementation
> > > > > > > > > > until we remove it from the project.
> > > > > > > > >
> > > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > > phase 1 will be merged.
> > > > > > > > > I think all tests in the package:
> > > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > > included in RunAll.
> > > > > > > > >
> > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > >
> > > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > > I changed to the following structure:
> > > > > > > > >
> > > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > > >
> > > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > > >
> > > > > > > > > > *3. Naming.*
> > > > > > > > >
> > > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > > manages several services, not single.
> > > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > > >
> > > > > > with
> > > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > > >
> > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > >
> > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > > name.
> > > > > > > > >
> > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > >
> > > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > > >
> > > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > > >
> > > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > > >
> > > > > > nizhikov@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hello, Denis.
> > > > > > > > > >
> > > > > > > > > > Great news.
> > > > > > > > > >
> > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > >
> > > > > > grid.*
> > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > >
> > > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > > >
> > > > > > > > > > Aggree. Let's do it.
> > > > > > > > > >
> > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > >
> > > > > > > > > > Agree. Lets's do it.
> > > > > > > > > >
> > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > >
> > > > > > other
> > > > > > > > > classes> with Services word in them.
> > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > >
> > > > > > *Service
> > > > > > > > > *instead.
> > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > >
> > > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > > >
> > > > > > > > > content for reader.
> > > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > > >
> > > > > > > > > > Same for deployment - if this message will initiate single
> > > > > >
> > > > > > deployment
> > > > > > > > > process then it should use deployment.
> > > > > > > > > > otherwise - deployments.
> > > > > > > > > >
> > > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > > >
> > > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > > Guys,
> > > > > > > > > > >
> > > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > > >
> > > > > > weeks.
> > > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > > >
> > > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > > >
> > > > > > > to
> > > > > > > > > avoid
> > > > > > > > > > > controversy.
> > > > > > > > > > >
> > > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > > >
> > > > > > grid.*
> > > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > > >
> > > > > > > > > implementation
> > > > > > > > > > > until we
> > > > > > > > > > > remove it from the project.
> > > > > > > > > > >
> > > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > > >
> > > > > > > field,
> > > > > > > > > that
> > > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > > >
> > > > > > markUndeploy(...)*
> > > > > > > > > looks
> > > > > > > > > > > wrong.
> > > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > > >
> > > > > > > > > > > *3. Naming.*
> > > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > > >
> > > > > > other
> > > > > > > > > classes
> > > > > > > > > > > with Services word in them.
> > > > > > > > > > > I think, they would look better if we use a singular word
> > > > > >
> > > > > > *Service
> > > > > > > > > *instead.
> > > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > > I propose the following class names:
> > > > > > > > > > >
> > > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > > >
> > > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > > >
> > > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > > >
> > > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > > >
> > > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > > >
> > > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > > >
> > > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > > >
> > > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > > >
> > > > > > > repeated
> > > > > > > > > > > renaming.
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > > >
> > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > >
> > > > > > > > > > > > Alexey,
> > > > > > > > > > > >
> > > > > > > > > > > > I don't see any problem in letting services work on a
> > > > > >
> > > > > > deactivated
> > > > > > > > > cluster.
> > > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > > >
> > > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > > >
> > > > > > their
> > > > > > > > > work,
> > > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > > >
> > > > > > deactivation.
> > > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > > >
> > > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > > Could you start another thread?
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > > >
> > > > > > > akuznetsov@apache.org
> > > > > > > > > > :
> > > > > > > > > > > >
> > > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > > >
> > > > > > > as a
> > > > > > > > > cluster
> > > > > > > > > > > > > singleton service.
> > > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > > >
> > > > > > > start
> > > > > > > > > > > > > separate java program.
> > > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > > >
> > > > > > > configuration.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > > >
> > > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > > >
> > > > > > redesign -
> > > > > > > > > phase 2" ?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Please let me know.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>
>
> --
> Best Regards, Vyacheslav D.



--
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Stanislav, thank you for the notes, most of them have been resolved. I
answered on GitHub.


On Sun, Dec 23, 2018 at 9:34 PM Stanislav Lukyanov
<st...@gmail.com> wrote:
>
> I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
> I’ve left some comments – almost all are about minor issues, grammar and code style.
>
> Stan
>
> From: Vyacheslav Daradur
> Sent: 21 декабря 2018 г. 14:58
> To: dev@ignite.apache.org
> Subject: Re: Service grid redesign
>
> Igniters,
>
> Please, let us know if someone is going to do an additional review?
>
> We should know can we merge the PR since it has been approved by
> Nikolay Izhikov and Denis Mekhanikov or we should wait for other
> community members.
>
> On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
> >
> > I think I found names which should satisfy me and Denis, and possibly Nikolay )
> >
> > See the following names (Actual name <- Previously used):
> >
> > - ServiceDeploymentManager <- ServicesDeploymentManager
> > - ServiceDeploymentActions <- ServicesDeploymentActions
> > - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> > - ServiceDeploymentTask <- ServicesDeploymentTask
> >
> > - ServiceDeploymentRequest <- ServiceDeploymentChange
> > - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> > - ServiceChangeAbstractRequest <- ServiceAbstractChange
> >
> > - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> > - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
> >
> > - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> > - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
> >
> > - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> > - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
> >
> > Also, I had a short talk with Alexey Goncharuk about the problem of
> > nullified custom messages. I changed the implementation to a lock-free
> > solution which allows us to nullify messages depend on an using
> > counter.
> >
> > In comparison with high priority listener, this allows us to not copy
> > custom discovery event in service deployment manager and work with the
> > original object.
> >
> > On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> > >
> > > Denis, great news!
> > >
> > > Alexey, Vova, Yakov, do you want to take a look at this PR?
> > >
> > >
> > >
> > > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > > Guys,
> > > >
> > > > I finished my code review. The pool request looks good to me.
> > > >
> > > > Does anybody else want to look at the changes?
> > > > There are a few points, that we didn't meet an agreement on,
> > > > though they don't affect the behaviour in any way:
> > > >
> > > >    - *Class naming. * See the discussion above.
> > > >    - *Unnecessary task object cleaning. *
> > > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > > >    and it should be removed.
> > > >    By the moment, when this method is called, the task object is removed
> > > >    from all collections anyway, so it's ready for garbage collection.
> > > >    Removing data from it doesn't help anybody.
> > > >    -
> > > > *Unnecessary tests. *ServiceInfoSelfTest and
> > > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > > >    I don't see any point in testing an interface implementation, that only
> > > >    saves some objects and returns them from certain methods.
> > > >    - Interface for events with servicesDeploymentActions() method.
> > > >    Take a look at the discussion:
> > > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > > >
> > > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > > clumsy to me.
> > > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > > be solved
> > > > by making *ServiceDiscoveryListener* a high priority listener.
> > > >
> > > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > > synchronized and
> > > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > > the event object.
> > > > But this solution is the same, it's just a matter of taste.
> > > >
> > > > If anybody wants to look the the code of the PR, please consider these
> > > > points as well.
> > > >
> > > > Denis
> > > >
> > > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > > Denis,
> > > > >
> > > > > I don't think that differences with your and my naming is huge :)
> > > > > And, it's definetely a matter of taste.
> > > > >
> > > > > If there is no any other issues with PR let's rename and move on! :)
> > > > >
> > > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > > >
> > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > >
> > > > > > "Service"
> > > > > >
> > > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > > 'IgniteServicesProcessor'?
> > > > > >
> > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > "Single deployments" doesn't sound right.
> > > > > >
> > > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > > - 'ServicesNodeDeploymentsResults'
> > > > > > - 'ServicesInstanceDeploymentsResults'
> > > > > >
> > > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Slava,
> > > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > > >
> > > > > > > Nik,
> > > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > > "Service",
> > > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > > >
> > > > > > "Services"
> > > > > > > for some reason.
> > > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > > I think, we should unify these names.
> > > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > > "Single deployments" doesn't sound right.
> > > > > > >
> > > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > > from GridDhtPartitionsFullMessage.
> > > > > > > It doesn't really reflect its function. This message is supposed to
> > > > >
> > > > > mark
> > > > > > > the point in time, when deployment is finished.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > >
> > > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > > >
> > > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > >
> > > > > > > > implementation
> > > > > > > > > until we remove it from the project.
> > > > > > > >
> > > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > > phase 1 will be merged.
> > > > > > > > I think all tests in the package:
> > > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > > included in RunAll.
> > > > > > > >
> > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > I think, this class should be splat into two.
> > > > > > > >
> > > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > > I changed to the following structure:
> > > > > > > >
> > > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > > }
> > > > > > > >
> > > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > > >     ServiceConfiguration cfg;
> > > > > > > > }
> > > > > > > >
> > > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > > >
> > > > > > > > I hope that further reviewers will agree with us.
> > > > > > > >
> > > > > > > > > *3. Naming.*
> > > > > > > >
> > > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > > manages several services, not single.
> > > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > > >
> > > > > with
> > > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > > >
> > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > >
> > > > > > DynamicServiceChangeRequest*
> > > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > > name.
> > > > > > > >
> > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > >
> > > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > > >
> > > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > > >
> > > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > > contains deployments of *full set of nodes*.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > > >
> > > > > nizhikov@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hello, Denis.
> > > > > > > > >
> > > > > > > > > Great news.
> > > > > > > > >
> > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > >
> > > > > grid.*
> > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > >
> > > > > > > > implementation> until we> remove it from the project.
> > > > > > > > >
> > > > > > > > > Aggree. Let's do it.
> > > > > > > > >
> > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > >
> > > > > > > > > Agree. Lets's do it.
> > > > > > > > >
> > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > >
> > > > > other
> > > > > > > > classes> with Services word in them.
> > > > > > > > > > I think, they would look better if we use a singular word
> > > > >
> > > > > *Service
> > > > > > > > *instead.
> > > > > > > > > > Same for *Deployments*.
> > > > > > > > >
> > > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > > >
> > > > > > > > content for reader.
> > > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > > >
> > > > > > > > > Same for deployment - if this message will initiate single
> > > > >
> > > > > deployment
> > > > > > > > process then it should use deployment.
> > > > > > > > > otherwise - deployments.
> > > > > > > > >
> > > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > > >
> > > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > > Guys,
> > > > > > > > > >
> > > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > > >
> > > > > weeks.
> > > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > > >
> > > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > > I am close to finishing my review.
> > > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > > >
> > > > > > to
> > > > > > > > avoid
> > > > > > > > > > controversy.
> > > > > > > > > >
> > > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > > >
> > > > > grid.*
> > > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > > >
> > > > > > > > implementation
> > > > > > > > > > until we
> > > > > > > > > > remove it from the project.
> > > > > > > > > >
> > > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > > >
> > > > > > field,
> > > > > > > > that
> > > > > > > > > > shows, what action it actually represents.
> > > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > > >
> > > > > markUndeploy(...)*
> > > > > > > > looks
> > > > > > > > > > wrong.
> > > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > > >
> > > > > > > > > > *3. Naming.*
> > > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > > >
> > > > > other
> > > > > > > > classes
> > > > > > > > > > with Services word in them.
> > > > > > > > > > I think, they would look better if we use a singular word
> > > > >
> > > > > *Service
> > > > > > > > *instead.
> > > > > > > > > > Same for *Deployments*.
> > > > > > > > > > I propose the following class names:
> > > > > > > > > >
> > > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > > >
> > > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > > >
> > > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > > >
> > > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > > >
> > > > > ServiceDeploymentFinishMessage*
> > > > > > > > > >
> > > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > > >
> > > > > ServiceSingleDeploymentResult*
> > > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > > >
> > > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > > >
> > > > > > repeated
> > > > > > > > > > renaming.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > > >
> > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > Alexey,
> > > > > > > > > > >
> > > > > > > > > > > I don't see any problem in letting services work on a
> > > > >
> > > > > deactivated
> > > > > > > > cluster.
> > > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > > >
> > > > > > > > > > > But it should be configurable. Services may need caches for
> > > > >
> > > > > their
> > > > > > > > work,
> > > > > > > > > > > so it's better to undeploy such services on cluster
> > > > >
> > > > > deactivation.
> > > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > > >
> > > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > > Could you start another thread?
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > > >
> > > > > > akuznetsov@apache.org
> > > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > > >
> > > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > > >
> > > > > > as a
> > > > > > > > cluster
> > > > > > > > > > > > singleton service.
> > > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > > >
> > > > > > start
> > > > > > > > > > > > separate java program.
> > > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > > >
> > > > > > configuration.
> > > > > > > > > > > >
> > > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > > >
> > > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > > >
> > > > > redesign -
> > > > > > > > phase 2" ?
> > > > > > > > > > > >
> > > > > > > > > > > > Please let me know.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>


--
Best Regards, Vyacheslav D.

RE: Service grid redesign

Posted by Stanislav Lukyanov <st...@gmail.com>.
I’ve done a quick superficial review. Didn’t look at the tests, didn’t dive into the design, etc, just the code.
I’ve left some comments – almost all are about minor issues, grammar and code style.

Stan 

From: Vyacheslav Daradur
Sent: 21 декабря 2018 г. 14:58
To: dev@ignite.apache.org
Subject: Re: Service grid redesign

Igniters,

Please, let us know if someone is going to do an additional review?

We should know can we merge the PR since it has been approved by
Nikolay Izhikov and Denis Mekhanikov or we should wait for other
community members.

On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> I think I found names which should satisfy me and Denis, and possibly Nikolay )
>
> See the following names (Actual name <- Previously used):
>
> - ServiceDeploymentManager <- ServicesDeploymentManager
> - ServiceDeploymentActions <- ServicesDeploymentActions
> - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> - ServiceDeploymentTask <- ServicesDeploymentTask
>
> - ServiceDeploymentRequest <- ServiceDeploymentChange
> - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> - ServiceChangeAbstractRequest <- ServiceAbstractChange
>
> - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
>
> - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
>
> - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
>
> Also, I had a short talk with Alexey Goncharuk about the problem of
> nullified custom messages. I changed the implementation to a lock-free
> solution which allows us to nullify messages depend on an using
> counter.
>
> In comparison with high priority listener, this allows us to not copy
> custom discovery event in service deployment manager and work with the
> original object.
>
> On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> >
> > Denis, great news!
> >
> > Alexey, Vova, Yakov, do you want to take a look at this PR?
> >
> >
> >
> > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > Guys,
> > >
> > > I finished my code review. The pool request looks good to me.
> > >
> > > Does anybody else want to look at the changes?
> > > There are a few points, that we didn't meet an agreement on,
> > > though they don't affect the behaviour in any way:
> > >
> > >    - *Class naming. * See the discussion above.
> > >    - *Unnecessary task object cleaning. *
> > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > >    and it should be removed.
> > >    By the moment, when this method is called, the task object is removed
> > >    from all collections anyway, so it's ready for garbage collection.
> > >    Removing data from it doesn't help anybody.
> > >    -
> > > *Unnecessary tests. *ServiceInfoSelfTest and
> > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > >    I don't see any point in testing an interface implementation, that only
> > >    saves some objects and returns them from certain methods.
> > >    - Interface for events with servicesDeploymentActions() method.
> > >    Take a look at the discussion:
> > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > >
> > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > clumsy to me.
> > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > be solved
> > > by making *ServiceDiscoveryListener* a high priority listener.
> > >
> > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > synchronized and
> > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > the event object.
> > > But this solution is the same, it's just a matter of taste.
> > >
> > > If anybody wants to look the the code of the PR, please consider these
> > > points as well.
> > >
> > > Denis
> > >
> > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > > Denis,
> > > >
> > > > I don't think that differences with your and my naming is huge :)
> > > > And, it's definetely a matter of taste.
> > > >
> > > > If there is no any other issues with PR let's rename and move on! :)
> > > >
> > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > >
> > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > >
> > > > > "Service"
> > > > >
> > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > 'IgniteServicesProcessor'?
> > > > >
> > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > "Single deployments" doesn't sound right.
> > > > >
> > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > - 'ServicesNodeDeploymentsResults'
> > > > > - 'ServicesInstanceDeploymentsResults'
> > > > >
> > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Slava,
> > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > >
> > > > > > Nik,
> > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > "Service",
> > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > >
> > > > > "Services"
> > > > > > for some reason.
> > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > I think, we should unify these names.
> > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > "Single deployments" doesn't sound right.
> > > > > >
> > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > from GridDhtPartitionsFullMessage.
> > > > > > It doesn't really reflect its function. This message is supposed to
> > > >
> > > > mark
> > > > > > the point in time, when deployment is finished.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > >
> > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation
> > > > > > > > until we remove it from the project.
> > > > > > >
> > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > phase 1 will be merged.
> > > > > > > I think all tests in the package:
> > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > included in RunAll.
> > > > > > >
> > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > I think, this class should be splat into two.
> > > > > > >
> > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > I changed to the following structure:
> > > > > > >
> > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > }
> > > > > > >
> > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > >     ServiceConfiguration cfg;
> > > > > > > }
> > > > > > >
> > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > >
> > > > > > > I hope that further reviewers will agree with us.
> > > > > > >
> > > > > > > > *3. Naming.*
> > > > > > >
> > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > manages several services, not single.
> > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > >
> > > > with
> > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > >
> > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > >
> > > > > DynamicServiceChangeRequest*
> > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > name.
> > > > > > >
> > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > >
> > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > >
> > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > >
> > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > contains deployments of *full set of nodes*.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > >
> > > > nizhikov@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hello, Denis.
> > > > > > > >
> > > > > > > > Great news.
> > > > > > > >
> > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > >
> > > > grid.*
> > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation> until we> remove it from the project.
> > > > > > > >
> > > > > > > > Aggree. Let's do it.
> > > > > > > >
> > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > I think, this class should be splat into two.
> > > > > > > >
> > > > > > > > Agree. Lets's do it.
> > > > > > > >
> > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > >
> > > > other
> > > > > > > classes> with Services word in them.
> > > > > > > > > I think, they would look better if we use a singular word
> > > >
> > > > *Service
> > > > > > > *instead.
> > > > > > > > > Same for *Deployments*.
> > > > > > > >
> > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > >
> > > > > > > content for reader.
> > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > >
> > > > > > > > Same for deployment - if this message will initiate single
> > > >
> > > > deployment
> > > > > > > process then it should use deployment.
> > > > > > > > otherwise - deployments.
> > > > > > > >
> > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > >
> > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > >
> > > > weeks.
> > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > >
> > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > I am close to finishing my review.
> > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > >
> > > > > to
> > > > > > > avoid
> > > > > > > > > controversy.
> > > > > > > > >
> > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > >
> > > > grid.*
> > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation
> > > > > > > > > until we
> > > > > > > > > remove it from the project.
> > > > > > > > >
> > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > >
> > > > > field,
> > > > > > > that
> > > > > > > > > shows, what action it actually represents.
> > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > >
> > > > markUndeploy(...)*
> > > > > > > looks
> > > > > > > > > wrong.
> > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > >
> > > > > > > > > *3. Naming.*
> > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > >
> > > > other
> > > > > > > classes
> > > > > > > > > with Services word in them.
> > > > > > > > > I think, they would look better if we use a singular word
> > > >
> > > > *Service
> > > > > > > *instead.
> > > > > > > > > Same for *Deployments*.
> > > > > > > > > I propose the following class names:
> > > > > > > > >
> > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > >
> > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > >
> > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > >
> > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > >
> > > > ServiceDeploymentFinishMessage*
> > > > > > > > >
> > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > >
> > > > ServiceSingleDeploymentResult*
> > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > >
> > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > >
> > > > > repeated
> > > > > > > > > renaming.
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > >
> > > > > dmekhanikov@gmail.com>:
> > > > > > > > >
> > > > > > > > > > Alexey,
> > > > > > > > > >
> > > > > > > > > > I don't see any problem in letting services work on a
> > > >
> > > > deactivated
> > > > > > > cluster.
> > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > >
> > > > > > > > > > But it should be configurable. Services may need caches for
> > > >
> > > > their
> > > > > > > work,
> > > > > > > > > > so it's better to undeploy such services on cluster
> > > >
> > > > deactivation.
> > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > >
> > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > Could you start another thread?
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > >
> > > > > akuznetsov@apache.org
> > > > > > > > :
> > > > > > > > > >
> > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > >
> > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > >
> > > > > as a
> > > > > > > cluster
> > > > > > > > > > > singleton service.
> > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > >
> > > > > start
> > > > > > > > > > > separate java program.
> > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > >
> > > > > configuration.
> > > > > > > > > > >
> > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > >
> > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > >
> > > > redesign -
> > > > > > > phase 2" ?
> > > > > > > > > > >
> > > > > > > > > > > Please let me know.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Igniters,

Please, let us know if someone is going to do an additional review?

We should know can we merge the PR since it has been approved by
Nikolay Izhikov and Denis Mekhanikov or we should wait for other
community members.

On Thu, Dec 20, 2018 at 7:52 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> I think I found names which should satisfy me and Denis, and possibly Nikolay )
>
> See the following names (Actual name <- Previously used):
>
> - ServiceDeploymentManager <- ServicesDeploymentManager
> - ServiceDeploymentActions <- ServicesDeploymentActions
> - ServiceDeploymentProcessId <- ServicesDeploymentProcessId
> - ServiceDeploymentTask <- ServicesDeploymentTask
>
> - ServiceDeploymentRequest <- ServiceDeploymentChange
> - ServiceUndeploymentRequest <- ServiceUndeploymentChange
> - ServiceChangeAbstractRequest <- ServiceAbstractChange
>
> - ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
> - ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage
>
> - ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
> - ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage
>
> - ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
> - ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData
>
> Also, I had a short talk with Alexey Goncharuk about the problem of
> nullified custom messages. I changed the implementation to a lock-free
> solution which allows us to nullify messages depend on an using
> counter.
>
> In comparison with high priority listener, this allows us to not copy
> custom discovery event in service deployment manager and work with the
> original object.
>
> On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
> >
> > Denis, great news!
> >
> > Alexey, Vova, Yakov, do you want to take a look at this PR?
> >
> >
> >
> > В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > > Guys,
> > >
> > > I finished my code review. The pool request looks good to me.
> > >
> > > Does anybody else want to look at the changes?
> > > There are a few points, that we didn't meet an agreement on,
> > > though they don't affect the behaviour in any way:
> > >
> > >    - *Class naming. * See the discussion above.
> > >    - *Unnecessary task object cleaning. *
> > >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> > >    and it should be removed.
> > >    By the moment, when this method is called, the task object is removed
> > >    from all collections anyway, so it's ready for garbage collection.
> > >    Removing data from it doesn't help anybody.
> > >    -
> > > *Unnecessary tests. *ServiceInfoSelfTest and
> > >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> > >    I don't see any point in testing an interface implementation, that only
> > >    saves some objects and returns them from certain methods.
> > >    - Interface for events with servicesDeploymentActions() method.
> > >    Take a look at the discussion:
> > >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> > >
> > > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > > clumsy to me.
> > > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > > be solved
> > > by making *ServiceDiscoveryListener* a high priority listener.
> > >
> > > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > > synchronized and
> > > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > > the event object.
> > > But this solution is the same, it's just a matter of taste.
> > >
> > > If anybody wants to look the the code of the PR, please consider these
> > > points as well.
> > >
> > > Denis
> > >
> > > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > > Denis,
> > > >
> > > > I don't think that differences with your and my naming is huge :)
> > > > And, it's definetely a matter of taste.
> > > >
> > > > If there is no any other issues with PR let's rename and move on! :)
> > > >
> > > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > > >
> > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > >
> > > > > "Service"
> > > > >
> > > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > > 'IgniteServicesProcessor'?
> > > > >
> > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > "Single deployments" doesn't sound right.
> > > > >
> > > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > > - 'ServicesNodeDeploymentsResults'
> > > > > - 'ServicesInstanceDeploymentsResults'
> > > > >
> > > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Slava,
> > > > > > I think, it's better to replace word "Change" with "Request".
> > > > > >
> > > > > > Nik,
> > > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > > "Service",
> > > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > > >
> > > > > "Services"
> > > > > > for some reason.
> > > > > > So, you need to remember, where Service and where Services is used.
> > > > > > I think, we should unify these names.
> > > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > > "Single deployments" doesn't sound right.
> > > > > >
> > > > > > ServicesFullDeploymentsMessage is derived
> > > > > > from GridDhtPartitionsFullMessage.
> > > > > > It doesn't really reflect its function. This message is supposed to
> > > >
> > > > mark
> > > > > > the point in time, when deployment is finished.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > >
> > > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > > >
> > > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation
> > > > > > > > until we remove it from the project.
> > > > > > >
> > > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > > phase 1 will be merged.
> > > > > > > I think all tests in the package:
> > > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > > included in RunAll.
> > > > > > >
> > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > I think, this class should be splat into two.
> > > > > > >
> > > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > > I changed to the following structure:
> > > > > > >
> > > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > > >     protected final IgniteUuid srvcId;
> > > > > > > }
> > > > > > >
> > > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > > >     ServiceConfiguration cfg;
> > > > > > > }
> > > > > > >
> > > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > > >
> > > > > > > I hope that further reviewers will agree with us.
> > > > > > >
> > > > > > > > *3. Naming.*
> > > > > > >
> > > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > > manages several services, not single.
> > > > > > > But, I understand Denis's point of view, we have a lot of classes
> > > >
> > > > with
> > > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > > >
> > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > >
> > > > > DynamicServiceChangeRequest*
> > > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > > name.
> > > > > > >
> > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > >
> > > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > > >
> > > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > > >
> > > > > > > This should be named similar way as the previous one, but the message
> > > > > > > contains deployments of *full set of nodes*.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > > >
> > > > nizhikov@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hello, Denis.
> > > > > > > >
> > > > > > > > Great news.
> > > > > > > >
> > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > >
> > > > grid.*
> > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation> until we> remove it from the project.
> > > > > > > >
> > > > > > > > Aggree. Let's do it.
> > > > > > > >
> > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > I think, this class should be splat into two.
> > > > > > > >
> > > > > > > > Agree. Lets's do it.
> > > > > > > >
> > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > >
> > > > other
> > > > > > > classes> with Services word in them.
> > > > > > > > > I think, they would look better if we use a singular word
> > > >
> > > > *Service
> > > > > > > *instead.
> > > > > > > > > Same for *Deployments*.
> > > > > > > >
> > > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > > >
> > > > > > > content for reader.
> > > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > > >
> > > > > > > > Same for deployment - if this message will initiate single
> > > >
> > > > deployment
> > > > > > > process then it should use deployment.
> > > > > > > > otherwise - deployments.
> > > > > > > >
> > > > > > > > So my opinion - it's better to keep current naming.
> > > > > > > >
> > > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > > >
> > > > weeks.
> > > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > > >
> > > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > > I am close to finishing my review.
> > > > > > > > > There are some points, that I'd like to settle in this discussion
> > > > >
> > > > > to
> > > > > > > avoid
> > > > > > > > > controversy.
> > > > > > > > >
> > > > > > > > > *1. Testing of the cache-based implementation of the service
> > > >
> > > > grid.*
> > > > > > > > > I think, we should make a test suite, that will test the old
> > > > > > >
> > > > > > > implementation
> > > > > > > > > until we
> > > > > > > > > remove it from the project.
> > > > > > > > >
> > > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > > I think, this class should be splat into two.
> > > > > > > > > I don't see any point in having a single class with "*flags"*
> > > > >
> > > > > field,
> > > > > > > that
> > > > > > > > > shows, what action it actually represents.
> > > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > > >
> > > > markUndeploy(...)*
> > > > > > > looks
> > > > > > > > > wrong.
> > > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > > >
> > > > > > > > > *3. Naming.*
> > > > > > > > > I suggest renaming the following classes:
> > > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > > >
> > > > other
> > > > > > > classes
> > > > > > > > > with Services word in them.
> > > > > > > > > I think, they would look better if we use a singular word
> > > >
> > > > *Service
> > > > > > > *instead.
> > > > > > > > > Same for *Deployments*.
> > > > > > > > > I propose the following class names:
> > > > > > > > >
> > > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > > >
> > > > ServiceJoiningNodeDiscoveryData*
> > > > > > > > >
> > > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > > >
> > > > > > > DynamicServiceChangeRequest*
> > > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > > *ServicesFullDeploymentsMessage ->
> > > >
> > > > ServiceDeploymentFinishMessage*
> > > > > > > > >
> > > > > > > > > *ServiceSingleDeploymentsResults ->
> > > >
> > > > ServiceSingleDeploymentResult*
> > > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > > >
> > > > > > > > > Let's do this as the final step of the code review to avoid
> > > > >
> > > > > repeated
> > > > > > > > > renaming.
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > > >
> > > > > dmekhanikov@gmail.com>:
> > > > > > > > >
> > > > > > > > > > Alexey,
> > > > > > > > > >
> > > > > > > > > > I don't see any problem in letting services work on a
> > > >
> > > > deactivated
> > > > > > > cluster.
> > > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > > Both of these features are available at all times.
> > > > > > > > > >
> > > > > > > > > > But it should be configurable. Services may need caches for
> > > >
> > > > their
> > > > > > > work,
> > > > > > > > > > so it's better to undeploy such services on cluster
> > > >
> > > > deactivation.
> > > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > > >
> > > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > > Could you start another thread?
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > > >
> > > > > akuznetsov@apache.org
> > > > > > > > :
> > > > > > > > > >
> > > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > > >
> > > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > > >
> > > > > as a
> > > > > > > cluster
> > > > > > > > > > > singleton service.
> > > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > > >
> > > > > start
> > > > > > > > > > > separate java program.
> > > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > > >
> > > > > configuration.
> > > > > > > > > > >
> > > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > > >
> > > > > > > > > > > Could we support mentioned features on "Service Grid
> > > >
> > > > redesign -
> > > > > > > phase 2" ?
> > > > > > > > > > >
> > > > > > > > > > > Please let me know.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
I think I found names which should satisfy me and Denis, and possibly Nikolay )

See the following names (Actual name <- Previously used):

- ServiceDeploymentManager <- ServicesDeploymentManager
- ServiceDeploymentActions <- ServicesDeploymentActions
- ServiceDeploymentProcessId <- ServicesDeploymentProcessId
- ServiceDeploymentTask <- ServicesDeploymentTask

- ServiceDeploymentRequest <- ServiceDeploymentChange
- ServiceUndeploymentRequest <- ServiceUndeploymentChange
- ServiceChangeAbstractRequest <- ServiceAbstractChange

- ServiceSingleNodeDeploymentResult <- ServiceSingleDeploymentsResults
- ServiceSingleNodeDeploymentResultBatch <- ServicesSingleDeploymentsMessage

- ServiceClusterDeploymentResult <- ServiceFullDeploymentsResults
- ServiceClusterDeploymentResultBatch <- ServicesFullDeploymentsMessage

- ServiceProcessorCommonDiscoveryData <- ServicesCommonDiscoveryData
- ServiceProcessorJoinNodeDiscoveryData <- ServicesJoinNodeDiscoveryData

Also, I had a short talk with Alexey Goncharuk about the problem of
nullified custom messages. I changed the implementation to a lock-free
solution which allows us to nullify messages depend on an using
counter.

In comparison with high priority listener, this allows us to not copy
custom discovery event in service deployment manager and work with the
original object.

On Thu, Dec 20, 2018 at 8:57 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> Denis, great news!
>
> Alexey, Vova, Yakov, do you want to take a look at this PR?
>
>
>
> В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> > Guys,
> >
> > I finished my code review. The pool request looks good to me.
> >
> > Does anybody else want to look at the changes?
> > There are a few points, that we didn't meet an agreement on,
> > though they don't affect the behaviour in any way:
> >
> >    - *Class naming. * See the discussion above.
> >    - *Unnecessary task object cleaning. *
> >    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
> >    and it should be removed.
> >    By the moment, when this method is called, the task object is removed
> >    from all collections anyway, so it's ready for garbage collection.
> >    Removing data from it doesn't help anybody.
> >    -
> > *Unnecessary tests. *ServiceInfoSelfTest and
> >    ServicesDeploymentProcessIdSelfTest look excessive to me.
> >    I don't see any point in testing an interface implementation, that only
> >    saves some objects and returns them from certain methods.
> >    - Interface for events with servicesDeploymentActions() method.
> >    Take a look at the discussion:
> >    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> >
> > Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> > clumsy to me.
> > The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> > be solved
> > by making *ServiceDiscoveryListener* a high priority listener.
> >
> > Or *DiscoveryCustomEvent#customMessage()* method could be marked
> > synchronized and
> > *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> > the event object.
> > But this solution is the same, it's just a matter of taste.
> >
> > If anybody wants to look the the code of the PR, please consider these
> > points as well.
> >
> > Denis
> >
> > ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> >
> > > Denis,
> > >
> > > I don't think that differences with your and my naming is huge :)
> > > And, it's definetely a matter of taste.
> > >
> > > If there is no any other issues with PR let's rename and move on! :)
> > >
> > > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > >
> > > > "Service"
> > > >
> > > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > > 'IgniteServicesProcessor'?
> > > >
> > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > "Single deployments" doesn't sound right.
> > > >
> > > > 'Single' means 'single node', maybe we should use one of the following:
> > > > - 'ServicesSingleNodeDeploymentsResults'
> > > > - 'ServicesNodeDeploymentsResults'
> > > > - 'ServicesInstanceDeploymentsResults'
> > > >
> > > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > > wrote:
> > > > >
> > > > > Slava,
> > > > > I think, it's better to replace word "Change" with "Request".
> > > > >
> > > > > Nik,
> > > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > > "Service",
> > > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > >
> > > > "Services"
> > > > > for some reason.
> > > > > So, you need to remember, where Service and where Services is used.
> > > > > I think, we should unify these names.
> > > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > > "Single deployments" doesn't sound right.
> > > > >
> > > > > ServicesFullDeploymentsMessage is derived
> > > > > from GridDhtPartitionsFullMessage.
> > > > > It doesn't really reflect its function. This message is supposed to
> > >
> > > mark
> > > > > the point in time, when deployment is finished.
> > > > >
> > > > > Denis
> > > > >
> > > > >
> > > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > >
> > > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > > I think, we should make a test suite, that will test the old
> > > > > >
> > > > > > implementation
> > > > > > > until we remove it from the project.
> > > > > >
> > > > > > Agree. This is exactly what should be done as the first step once
> > > > > > phase 1 will be merged.
> > > > > > I think all tests in the package:
> > > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > > separate test-suite and new build-plan should be added on TC and
> > > > > > included in RunAll.
> > > > > >
> > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > I think, this class should be splat into two.
> > > > > >
> > > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > > I changed to the following structure:
> > > > > >
> > > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > > >     protected final IgniteUuid srvcId;
> > > > > > }
> > > > > >
> > > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > > >     ServiceConfiguration cfg;
> > > > > > }
> > > > > >
> > > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > >
> > > > > > I hope that further reviewers will agree with us.
> > > > > >
> > > > > > > *3. Naming.*
> > > > > >
> > > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > > manages several services, not single.
> > > > > > But, I understand Denis's point of view, we have a lot of classes
> > >
> > > with
> > > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > >
> > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > >
> > > > DynamicServiceChangeRequest*
> > > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > > name.
> > > > > >
> > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > >
> > > > > > It's not a response and is not sent to the sender. This message is
> > > > > > sent to the coordinator and contains *single node* deployments.
> > > > > >
> > > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > >
> > > > > > This should be named similar way as the previous one, but the message
> > > > > > contains deployments of *full set of nodes*.
> > > > > >
> > > > > >
> > > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > >
> > > nizhikov@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello, Denis.
> > > > > > >
> > > > > > > Great news.
> > > > > > >
> > > > > > > > *1. Testing of the cache-based implementation of the service
> > >
> > > grid.*
> > > > > > > > I think, we should make a test suite, that will test the old
> > > > > >
> > > > > > implementation> until we> remove it from the project.
> > > > > > >
> > > > > > > Aggree. Let's do it.
> > > > > > >
> > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > I think, this class should be splat into two.
> > > > > > >
> > > > > > > Agree. Lets's do it.
> > > > > > >
> > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > >
> > > other
> > > > > > classes> with Services word in them.
> > > > > > > > I think, they would look better if we use a singular word
> > >
> > > *Service
> > > > > > *instead.
> > > > > > > > Same for *Deployments*.
> > > > > > >
> > > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > >
> > > > > > content for reader.
> > > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > >
> > > > > > > Same for deployment - if this message will initiate single
> > >
> > > deployment
> > > > > > process then it should use deployment.
> > > > > > > otherwise - deployments.
> > > > > > >
> > > > > > > So my opinion - it's better to keep current naming.
> > > > > > >
> > > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > I've been looking through the PR by Vyacheslav for past few
> > >
> > > weeks.
> > > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > >
> > > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > > I am close to finishing my review.
> > > > > > > > There are some points, that I'd like to settle in this discussion
> > > >
> > > > to
> > > > > > avoid
> > > > > > > > controversy.
> > > > > > > >
> > > > > > > > *1. Testing of the cache-based implementation of the service
> > >
> > > grid.*
> > > > > > > > I think, we should make a test suite, that will test the old
> > > > > >
> > > > > > implementation
> > > > > > > > until we
> > > > > > > > remove it from the project.
> > > > > > > >
> > > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > > I think, this class should be splat into two.
> > > > > > > > I don't see any point in having a single class with "*flags"*
> > > >
> > > > field,
> > > > > > that
> > > > > > > > shows, what action it actually represents.
> > > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > >
> > > markUndeploy(...)*
> > > > > > looks
> > > > > > > > wrong.
> > > > > > > > Why not have a separate message type for each action instead?
> > > > > > > >
> > > > > > > > *3. Naming.*
> > > > > > > > I suggest renaming the following classes:
> > > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > >
> > > other
> > > > > > classes
> > > > > > > > with Services word in them.
> > > > > > > > I think, they would look better if we use a singular word
> > >
> > > *Service
> > > > > > *instead.
> > > > > > > > Same for *Deployments*.
> > > > > > > > I propose the following class names:
> > > > > > > >
> > > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > > *ServicesJoinNodeDiscoveryData ->
> > >
> > > ServiceJoiningNodeDiscoveryData*
> > > > > > > >
> > > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > >
> > > > > > DynamicServiceChangeRequest*
> > > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > > *ServicesFullDeploymentsMessage ->
> > >
> > > ServiceDeploymentFinishMessage*
> > > > > > > >
> > > > > > > > *ServiceSingleDeploymentsResults ->
> > >
> > > ServiceSingleDeploymentResult*
> > > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > >
> > > > > > > > Let's do this as the final step of the code review to avoid
> > > >
> > > > repeated
> > > > > > > > renaming.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > >
> > > > dmekhanikov@gmail.com>:
> > > > > > > >
> > > > > > > > > Alexey,
> > > > > > > > >
> > > > > > > > > I don't see any problem in letting services work on a
> > >
> > > deactivated
> > > > > > cluster.
> > > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > > Both of these features are available at all times.
> > > > > > > > >
> > > > > > > > > But it should be configurable. Services may need caches for
> > >
> > > their
> > > > > > work,
> > > > > > > > > so it's better to undeploy such services on cluster
> > >
> > > deactivation.
> > > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > >
> > > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > > Could you start another thread?
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > >
> > > > akuznetsov@apache.org
> > > > > > > :
> > > > > > > > >
> > > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > >
> > > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > >
> > > > as a
> > > > > > cluster
> > > > > > > > > > singleton service.
> > > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > >
> > > > start
> > > > > > > > > > separate java program.
> > > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > >
> > > > configuration.
> > > > > > > > > >
> > > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > >
> > > > > > > > > > Could we support mentioned features on "Service Grid
> > >
> > > redesign -
> > > > > > phase 2" ?
> > > > > > > > > >
> > > > > > > > > > Please let me know.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Alexey Kuznetsov
> > > > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Denis, great news!

Alexey, Vova, Yakov, do you want to take a look at this PR?



В Ср, 19/12/2018 в 18:47 +0300, Denis Mekhanikov пишет:
> Guys,
> 
> I finished my code review. The pool request looks good to me.
> 
> Does anybody else want to look at the changes?
> There are a few points, that we didn't meet an agreement on,
> though they don't affect the behaviour in any way:
> 
>    - *Class naming. * See the discussion above.
>    - *Unnecessary task object cleaning. *
>    IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
>    and it should be removed.
>    By the moment, when this method is called, the task object is removed
>    from all collections anyway, so it's ready for garbage collection.
>    Removing data from it doesn't help anybody.
>    -
> *Unnecessary tests. *ServiceInfoSelfTest and
>    ServicesDeploymentProcessIdSelfTest look excessive to me.
>    I don't see any point in testing an interface implementation, that only
>    saves some objects and returns them from certain methods.
>    - Interface for events with servicesDeploymentActions() method.
>    Take a look at the discussion:
>    https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342
> 
> Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
> clumsy to me.
> The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
> be solved
> by making *ServiceDiscoveryListener* a high priority listener.
> 
> Or *DiscoveryCustomEvent#customMessage()* method could be marked
> synchronized and
> *GridEventStorageManager#notifyListeners(..)* method could synchronize on
> the event object.
> But this solution is the same, it's just a matter of taste.
> 
> If anybody wants to look the the code of the PR, please consider these
> points as well.
> 
> Denis
> 
> ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:
> 
> > Denis,
> > 
> > I don't think that differences with your and my naming is huge :)
> > And, it's definetely a matter of taste.
> > 
> > If there is no any other issues with PR let's rename and move on! :)
> > 
> > ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
> > 
> > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > 
> > > "Service"
> > > 
> > > Maybe we should rename new 'IgniteServiceProcessor' to
> > > 'IgniteServicesProcessor'?
> > > 
> > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > "Single deployments" doesn't sound right.
> > > 
> > > 'Single' means 'single node', maybe we should use one of the following:
> > > - 'ServicesSingleNodeDeploymentsResults'
> > > - 'ServicesNodeDeploymentsResults'
> > > - 'ServicesInstanceDeploymentsResults'
> > > 
> > > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > > wrote:
> > > > 
> > > > Slava,
> > > > I think, it's better to replace word "Change" with "Request".
> > > > 
> > > > Nik,
> > > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > > "Service",
> > > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > > 
> > > "Services"
> > > > for some reason.
> > > > So, you need to remember, where Service and where Services is used.
> > > > I think, we should unify these names.
> > > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > > "Single deployments" doesn't sound right.
> > > > 
> > > > ServicesFullDeploymentsMessage is derived
> > > > from GridDhtPartitionsFullMessage.
> > > > It doesn't really reflect its function. This message is supposed to
> > 
> > mark
> > > > the point in time, when deployment is finished.
> > > > 
> > > > Denis
> > > > 
> > > > 
> > > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > > > 
> > > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > > I think, we should make a test suite, that will test the old
> > > > > 
> > > > > implementation
> > > > > > until we remove it from the project.
> > > > > 
> > > > > Agree. This is exactly what should be done as the first step once
> > > > > phase 1 will be merged.
> > > > > I think all tests in the package:
> > > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > > separate test-suite and new build-plan should be added on TC and
> > > > > included in RunAll.
> > > > > 
> > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > I think, this class should be splat into two.
> > > > > 
> > > > > Personally, I agree, but I have faced opposition at the design step.
> > > > > I changed to the following structure:
> > > > > 
> > > > > abstract class ServiceAbstractChange implements Serializable {
> > > > >     protected final IgniteUuid srvcId;
> > > > > }
> > > > > 
> > > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > > >     ServiceConfiguration cfg;
> > > > > }
> > > > > 
> > > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > > > 
> > > > > I hope that further reviewers will agree with us.
> > > > > 
> > > > > > *3. Naming.*
> > > > > 
> > > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > > manages several services, not single.
> > > > > But, I understand Denis's point of view, we have a lot of classes
> > 
> > with
> > > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > > > 
> > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > 
> > > DynamicServiceChangeRequest*
> > > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > > name.
> > > > > 
> > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > 
> > > > > It's not a response and is not sent to the sender. This message is
> > > > > sent to the coordinator and contains *single node* deployments.
> > > > > 
> > > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > > 
> > > > > This should be named similar way as the previous one, but the message
> > > > > contains deployments of *full set of nodes*.
> > > > > 
> > > > > 
> > > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> > 
> > nizhikov@apache.org>
> > > > > wrote:
> > > > > > 
> > > > > > Hello, Denis.
> > > > > > 
> > > > > > Great news.
> > > > > > 
> > > > > > > *1. Testing of the cache-based implementation of the service
> > 
> > grid.*
> > > > > > > I think, we should make a test suite, that will test the old
> > > > > 
> > > > > implementation> until we> remove it from the project.
> > > > > > 
> > > > > > Aggree. Let's do it.
> > > > > > 
> > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > I think, this class should be splat into two.
> > > > > > 
> > > > > > Agree. Lets's do it.
> > > > > > 
> > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > 
> > other
> > > > > classes> with Services word in them.
> > > > > > > I think, they would look better if we use a singular word
> > 
> > *Service
> > > > > *instead.
> > > > > > > Same for *Deployments*.
> > > > > > 
> > > > > > Personally, I want that names as clearly as possible reflects class
> > > > > 
> > > > > content for reader.
> > > > > > If we deploy *several* services then it has to be Service*S*.
> > > > > > 
> > > > > > Same for deployment - if this message will initiate single
> > 
> > deployment
> > > > > process then it should use deployment.
> > > > > > otherwise - deployments.
> > > > > > 
> > > > > > So my opinion - it's better to keep current naming.
> > > > > > 
> > > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > > Guys,
> > > > > > > 
> > > > > > > I've been looking through the PR by Vyacheslav for past few
> > 
> > weeks.
> > > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > > > 
> > > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > > I am close to finishing my review.
> > > > > > > There are some points, that I'd like to settle in this discussion
> > > 
> > > to
> > > > > avoid
> > > > > > > controversy.
> > > > > > > 
> > > > > > > *1. Testing of the cache-based implementation of the service
> > 
> > grid.*
> > > > > > > I think, we should make a test suite, that will test the old
> > > > > 
> > > > > implementation
> > > > > > > until we
> > > > > > > remove it from the project.
> > > > > > > 
> > > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > > I think, this class should be splat into two.
> > > > > > > I don't see any point in having a single class with "*flags"*
> > > 
> > > field,
> > > > > that
> > > > > > > shows, what action it actually represents.
> > > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> > 
> > markUndeploy(...)*
> > > > > looks
> > > > > > > wrong.
> > > > > > > Why not have a separate message type for each action instead?
> > > > > > > 
> > > > > > > *3. Naming.*
> > > > > > > I suggest renaming the following classes:
> > > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> > 
> > other
> > > > > classes
> > > > > > > with Services word in them.
> > > > > > > I think, they would look better if we use a singular word
> > 
> > *Service
> > > > > *instead.
> > > > > > > Same for *Deployments*.
> > > > > > > I propose the following class names:
> > > > > > > 
> > > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > > *ServicesJoinNodeDiscoveryData ->
> > 
> > ServiceJoiningNodeDiscoveryData*
> > > > > > > 
> > > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > > 
> > > > > DynamicServiceChangeRequest*
> > > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > > *ServicesFullDeploymentsMessage ->
> > 
> > ServiceDeploymentFinishMessage*
> > > > > > > 
> > > > > > > *ServiceSingleDeploymentsResults ->
> > 
> > ServiceSingleDeploymentResult*
> > > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > > > 
> > > > > > > Let's do this as the final step of the code review to avoid
> > > 
> > > repeated
> > > > > > > renaming.
> > > > > > > 
> > > > > > > Denis
> > > > > > > 
> > > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > > 
> > > dmekhanikov@gmail.com>:
> > > > > > > 
> > > > > > > > Alexey,
> > > > > > > > 
> > > > > > > > I don't see any problem in letting services work on a
> > 
> > deactivated
> > > > > cluster.
> > > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > > Both of these features are available at all times.
> > > > > > > > 
> > > > > > > > But it should be configurable. Services may need caches for
> > 
> > their
> > > > > work,
> > > > > > > > so it's better to undeploy such services on cluster
> > 
> > deactivation.
> > > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > > > 
> > > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > > Could you start another thread?
> > > > > > > > 
> > > > > > > > Denis
> > > > > > > > 
> > > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > > 
> > > akuznetsov@apache.org
> > > > > > :
> > > > > > > > 
> > > > > > > > > Hi,   Vyacheslav!
> > > > > > > > > 
> > > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > > 
> > > as a
> > > > > cluster
> > > > > > > > > singleton service.
> > > > > > > > > It will improve Web Console UX, because it will not needed to
> > > 
> > > start
> > > > > > > > > separate java program.
> > > > > > > > > Just start cluster with Web agent enabled on cluster
> > > 
> > > configuration.
> > > > > > > > > 
> > > > > > > > > But in order to do this, I need that services should:
> > > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > > > 
> > > > > > > > > Could we support mentioned features on "Service Grid
> > 
> > redesign -
> > > > > phase 2" ?
> > > > > > > > > 
> > > > > > > > > Please let me know.
> > > > > > > > > 
> > > > > > > > > --
> > > > > > > > > Alexey Kuznetsov
> > > > > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > > 
> > > 
> > > 
> > > 
> > > --
> > > Best Regards, Vyacheslav D.
> > >

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Guys,

I finished my code review. The pool request looks good to me.

Does anybody else want to look at the changes?
There are a few points, that we didn't meet an agreement on,
though they don't affect the behaviour in any way:

   - *Class naming. * See the discussion above.
   - *Unnecessary task object cleaning. *
   IMO, ServicesDeploymentTask#clear() method doesn't do anything useful,
   and it should be removed.
   By the moment, when this method is called, the task object is removed
   from all collections anyway, so it's ready for garbage collection.
   Removing data from it doesn't help anybody.
   -
*Unnecessary tests. *ServiceInfoSelfTest and
   ServicesDeploymentProcessIdSelfTest look excessive to me.
   I don't see any point in testing an interface implementation, that only
   saves some objects and returns them from certain methods.
   - Interface for events with servicesDeploymentActions() method.
   Take a look at the discussion:
   https://github.com/apache/ignite/pull/4434/files/30e69d9a53ce6ea16c4e9d15354e94360caa719d#r239442342

Also solution with *DiscoveryCustomEvent#nullifyingCustomMsgLock* looks
clumsy to me.
The problem with nullifying of *DiscoveryCustomEvent#customMsg* field can
be solved
by making *ServiceDiscoveryListener* a high priority listener.

Or *DiscoveryCustomEvent#customMessage()* method could be marked
synchronized and
*GridEventStorageManager#notifyListeners(..)* method could synchronize on
the event object.
But this solution is the same, it's just a matter of taste.

If anybody wants to look the the code of the PR, please consider these
points as well.

Denis

ср, 19 дек. 2018 г. в 17:37, Nikolay Izhikov <ni...@apache.org>:

> Denis,
>
> I don't think that differences with your and my naming is huge :)
> And, it's definetely a matter of taste.
>
> If there is no any other issues with PR let's rename and move on! :)
>
> ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:
>
> > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > "Service"
> >
> > Maybe we should rename new 'IgniteServiceProcessor' to
> > 'IgniteServicesProcessor'?
> >
> > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > "Single deployments" doesn't sound right.
> >
> > 'Single' means 'single node', maybe we should use one of the following:
> > - 'ServicesSingleNodeDeploymentsResults'
> > - 'ServicesNodeDeploymentsResults'
> > - 'ServicesInstanceDeploymentsResults'
> >
> > On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> > wrote:
> > >
> > > Slava,
> > > I think, it's better to replace word "Change" with "Request".
> > >
> > > Nik,
> > > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > > "Service",
> > > ServicesDeploymentManager and ServicesDeploymentTask with plural
> > "Services"
> > > for some reason.
> > > So, you need to remember, where Service and where Services is used.
> > > I think, we should unify these names.
> > > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > > "Single deployments" doesn't sound right.
> > >
> > > ServicesFullDeploymentsMessage is derived
> > > from GridDhtPartitionsFullMessage.
> > > It doesn't really reflect its function. This message is supposed to
> mark
> > > the point in time, when deployment is finished.
> > >
> > > Denis
> > >
> > >
> > > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > >*1. Testing of the cache-based implementation of the service grid.*
> > > > > I think, we should make a test suite, that will test the old
> > > > implementation
> > > > > until we remove it from the project.
> > > >
> > > > Agree. This is exactly what should be done as the first step once
> > > > phase 1 will be merged.
> > > > I think all tests in the package:
> > > > "org.apache.ignite.internal.processors.service" should be moved to
> > > > separate test-suite and new build-plan should be added on TC and
> > > > included in RunAll.
> > > >
> > > > > *2. DynamicServiceChangeRequest.*
> > > > > I think, this class should be splat into two.
> > > >
> > > > Personally, I agree, but I have faced opposition at the design step.
> > > > I changed to the following structure:
> > > >
> > > > abstract class ServiceAbstractChange implements Serializable {
> > > >     protected final IgniteUuid srvcId;
> > > > }
> > > >
> > > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > > >     ServiceConfiguration cfg;
> > > > }
> > > >
> > > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > > >
> > > > I hope that further reviewers will agree with us.
> > > >
> > > > > *3. Naming.*
> > > >
> > > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > > Personally, I agree with Nikolay, because it's more descriptive since
> > > > manages several services, not single.
> > > > But, I understand Denis's point of view, we have a lot of classes
> with
> > > > "Service" prefix in naming and "Services" looks a bit alien.
> > > >
> > > > > *DynamicServicesChangeRequestBatchMessage ->
> > DynamicServiceChangeRequest*
> > > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > > name.
> > > >
> > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > It's not a response and is not sent to the sender. This message is
> > > > sent to the coordinator and contains *single node* deployments.
> > > >
> > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > This should be named similar way as the previous one, but the message
> > > > contains deployments of *full set of nodes*.
> > > >
> > > >
> > > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <
> nizhikov@apache.org>
> > > > wrote:
> > > > >
> > > > > Hello, Denis.
> > > > >
> > > > > Great news.
> > > > >
> > > > > > *1. Testing of the cache-based implementation of the service
> grid.*
> > > > > > I think, we should make a test suite, that will test the old
> > > > implementation> until we> remove it from the project.
> > > > >
> > > > > Aggree. Let's do it.
> > > > >
> > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > I think, this class should be splat into two.
> > > > >
> > > > > Agree. Lets's do it.
> > > > >
> > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> other
> > > > classes> with Services word in them.
> > > > > > I think, they would look better if we use a singular word
> *Service
> > > > *instead.
> > > > > > Same for *Deployments*.
> > > > >
> > > > > Personally, I want that names as clearly as possible reflects class
> > > > content for reader.
> > > > > If we deploy *several* services then it has to be Service*S*.
> > > > >
> > > > > Same for deployment - if this message will initiate single
> deployment
> > > > process then it should use deployment.
> > > > > otherwise - deployments.
> > > > >
> > > > > So my opinion - it's better to keep current naming.
> > > > >
> > > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > > Guys,
> > > > > >
> > > > > > I've been looking through the PR by Vyacheslav for past few
> weeks.
> > > > > > Slava, great job! You've done an impressive amount of work.
> > > > > >
> > > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > > I am close to finishing my review.
> > > > > > There are some points, that I'd like to settle in this discussion
> > to
> > > > avoid
> > > > > > controversy.
> > > > > >
> > > > > > *1. Testing of the cache-based implementation of the service
> grid.*
> > > > > > I think, we should make a test suite, that will test the old
> > > > implementation
> > > > > > until we
> > > > > > remove it from the project.
> > > > > >
> > > > > > *2. DynamicServiceChangeRequest.*
> > > > > > I think, this class should be splat into two.
> > > > > > I don't see any point in having a single class with "*flags"*
> > field,
> > > > that
> > > > > > shows, what action it actually represents.
> > > > > > Usage of *deploy(), markDeploy(...), undeploy(),
> markUndeploy(...)*
> > > > looks
> > > > > > wrong.
> > > > > > Why not have a separate message type for each action instead?
> > > > > >
> > > > > > *3. Naming.*
> > > > > > I suggest renaming the following classes:
> > > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all
> other
> > > > classes
> > > > > > with Services word in them.
> > > > > > I think, they would look better if we use a singular word
> *Service
> > > > *instead.
> > > > > > Same for *Deployments*.
> > > > > > I propose the following class names:
> > > > > >
> > > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > > *ServicesJoinNodeDiscoveryData ->
> ServiceJoiningNodeDiscoveryData*
> > > > > >
> > > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > > DynamicServiceChangeRequest*
> > > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > > *ServicesFullDeploymentsMessage ->
> ServiceDeploymentFinishMessage*
> > > > > >
> > > > > > *ServiceSingleDeploymentsResults ->
> ServiceSingleDeploymentResult*
> > > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > > >
> > > > > > Let's do this as the final step of the code review to avoid
> > repeated
> > > > > > renaming.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> > dmekhanikov@gmail.com>:
> > > > > >
> > > > > > > Alexey,
> > > > > > >
> > > > > > > I don't see any problem in letting services work on a
> deactivated
> > > > cluster.
> > > > > > > All services need is discovery messages and compute tasks.
> > > > > > > Both of these features are available at all times.
> > > > > > >
> > > > > > > But it should be configurable. Services may need caches for
> their
> > > > work,
> > > > > > > so it's better to undeploy such services on cluster
> deactivation.
> > > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > > >
> > > > > > > I think, this topic deserves a separate discussion.
> > > > > > > Could you start another thread?
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> > akuznetsov@apache.org
> > > > >:
> > > > > > >
> > > > > > > > Hi,   Vyacheslav!
> > > > > > > >
> > > > > > > > I'm thinking about to use Services API to implement Web Agent
> > as a
> > > > cluster
> > > > > > > > singleton service.
> > > > > > > > It will improve Web Console UX, because it will not needed to
> > start
> > > > > > > > separate java program.
> > > > > > > > Just start cluster with Web agent enabled on cluster
> > configuration.
> > > > > > > >
> > > > > > > > But in order to do this, I need that services should:
> > > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > > >
> > > > > > > > Could we support mentioned features on "Service Grid
> redesign -
> > > > phase 2" ?
> > > > > > > >
> > > > > > > > Please let me know.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexey Kuznetsov
> > > > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Denis,

I don't think that differences with your and my naming is huge :)
And, it's definetely a matter of taste.

If there is no any other issues with PR let's rename and move on! :)

ср, 19 дек. 2018 г. в 17:32, Vyacheslav Daradur <da...@gmail.com>:

> > We have IgniteServiceProcessor and GridServiceProcessor with singular
> "Service"
>
> Maybe we should rename new 'IgniteServiceProcessor' to
> 'IgniteServicesProcessor'?
>
> > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > "Single deployments" doesn't sound right.
>
> 'Single' means 'single node', maybe we should use one of the following:
> - 'ServicesSingleNodeDeploymentsResults'
> - 'ServicesNodeDeploymentsResults'
> - 'ServicesInstanceDeploymentsResults'
>
> On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com>
> wrote:
> >
> > Slava,
> > I think, it's better to replace word "Change" with "Request".
> >
> > Nik,
> > We have IgniteServiceProcessor and GridServiceProcessor with singular
> > "Service",
> > ServicesDeploymentManager and ServicesDeploymentTask with plural
> "Services"
> > for some reason.
> > So, you need to remember, where Service and where Services is used.
> > I think, we should unify these names.
> > And ServiceSingleDeploymentsResults name doesn't make sense to me.
> > "Single deployments" doesn't sound right.
> >
> > ServicesFullDeploymentsMessage is derived
> > from GridDhtPartitionsFullMessage.
> > It doesn't really reflect its function. This message is supposed to mark
> > the point in time, when deployment is finished.
> >
> > Denis
> >
> >
> > пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
> >
> > > >*1. Testing of the cache-based implementation of the service grid.*
> > > > I think, we should make a test suite, that will test the old
> > > implementation
> > > > until we remove it from the project.
> > >
> > > Agree. This is exactly what should be done as the first step once
> > > phase 1 will be merged.
> > > I think all tests in the package:
> > > "org.apache.ignite.internal.processors.service" should be moved to
> > > separate test-suite and new build-plan should be added on TC and
> > > included in RunAll.
> > >
> > > > *2. DynamicServiceChangeRequest.*
> > > > I think, this class should be splat into two.
> > >
> > > Personally, I agree, but I have faced opposition at the design step.
> > > I changed to the following structure:
> > >
> > > abstract class ServiceAbstractChange implements Serializable {
> > >     protected final IgniteUuid srvcId;
> > > }
> > >
> > > class ServiceDeploymentChange extends ServiceAbstractChange {
> > >     ServiceConfiguration cfg;
> > > }
> > >
> > > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> > >
> > > I hope that further reviewers will agree with us.
> > >
> > > > *3. Naming.*
> > >
> > > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > > Personally, I agree with Nikolay, because it's more descriptive since
> > > manages several services, not single.
> > > But, I understand Denis's point of view, we have a lot of classes with
> > > "Service" prefix in naming and "Services" looks a bit alien.
> > >
> > > > *DynamicServicesChangeRequestBatchMessage ->
> DynamicServiceChangeRequest*
> > > Prefix "Dynamic" has no sense anymore since we reworked message
> > > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > > name.
> > >
> > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > It's not a response and is not sent to the sender. This message is
> > > sent to the coordinator and contains *single node* deployments.
> > >
> > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > This should be named similar way as the previous one, but the message
> > > contains deployments of *full set of nodes*.
> > >
> > >
> > > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <ni...@apache.org>
> > > wrote:
> > > >
> > > > Hello, Denis.
> > > >
> > > > Great news.
> > > >
> > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > I think, we should make a test suite, that will test the old
> > > implementation> until we> remove it from the project.
> > > >
> > > > Aggree. Let's do it.
> > > >
> > > > > *2. DynamicServiceChangeRequest.*
> > > > > I think, this class should be splat into two.
> > > >
> > > > Agree. Lets's do it.
> > > >
> > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> > > classes> with Services word in them.
> > > > > I think, they would look better if we use a singular word *Service
> > > *instead.
> > > > > Same for *Deployments*.
> > > >
> > > > Personally, I want that names as clearly as possible reflects class
> > > content for reader.
> > > > If we deploy *several* services then it has to be Service*S*.
> > > >
> > > > Same for deployment - if this message will initiate single deployment
> > > process then it should use deployment.
> > > > otherwise - deployments.
> > > >
> > > > So my opinion - it's better to keep current naming.
> > > >
> > > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > > Guys,
> > > > >
> > > > > I've been looking through the PR by Vyacheslav for past few weeks.
> > > > > Slava, great job! You've done an impressive amount of work.
> > > > >
> > > > > I posted my comments to the PR and had a few calls with Slava.
> > > > > I am close to finishing my review.
> > > > > There are some points, that I'd like to settle in this discussion
> to
> > > avoid
> > > > > controversy.
> > > > >
> > > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > > I think, we should make a test suite, that will test the old
> > > implementation
> > > > > until we
> > > > > remove it from the project.
> > > > >
> > > > > *2. DynamicServiceChangeRequest.*
> > > > > I think, this class should be splat into two.
> > > > > I don't see any point in having a single class with "*flags"*
> field,
> > > that
> > > > > shows, what action it actually represents.
> > > > > Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)*
> > > looks
> > > > > wrong.
> > > > > Why not have a separate message type for each action instead?
> > > > >
> > > > > *3. Naming.*
> > > > > I suggest renaming the following classes:
> > > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> > > classes
> > > > > with Services word in them.
> > > > > I think, they would look better if we use a singular word *Service
> > > *instead.
> > > > > Same for *Deployments*.
> > > > > I propose the following class names:
> > > > >
> > > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > > *ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*
> > > > >
> > > > > *DynamicServicesChangeRequestBatchMessage ->
> > > DynamicServiceChangeRequest*
> > > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > > >
> > > > > *ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
> > > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > > >
> > > > > Let's do this as the final step of the code review to avoid
> repeated
> > > > > renaming.
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <
> dmekhanikov@gmail.com>:
> > > > >
> > > > > > Alexey,
> > > > > >
> > > > > > I don't see any problem in letting services work on a deactivated
> > > cluster.
> > > > > > All services need is discovery messages and compute tasks.
> > > > > > Both of these features are available at all times.
> > > > > >
> > > > > > But it should be configurable. Services may need caches for their
> > > work,
> > > > > > so it's better to undeploy such services on cluster deactivation.
> > > > > > We may introduce a new property in ServiceConfiguration.
> > > > > >
> > > > > > I think, this topic deserves a separate discussion.
> > > > > > Could you start another thread?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <
> akuznetsov@apache.org
> > > >:
> > > > > >
> > > > > > > Hi,   Vyacheslav!
> > > > > > >
> > > > > > > I'm thinking about to use Services API to implement Web Agent
> as a
> > > cluster
> > > > > > > singleton service.
> > > > > > > It will improve Web Console UX, because it will not needed to
> start
> > > > > > > separate java program.
> > > > > > > Just start cluster with Web agent enabled on cluster
> configuration.
> > > > > > >
> > > > > > > But in order to do this, I need that services should:
> > > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > > >
> > > > > > > Could we support mentioned features on "Service Grid redesign -
> > > phase 2" ?
> > > > > > >
> > > > > > > Please let me know.
> > > > > > >
> > > > > > > --
> > > > > > > Alexey Kuznetsov
> > > > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
> We have IgniteServiceProcessor and GridServiceProcessor with singular "Service"

Maybe we should rename new 'IgniteServiceProcessor' to
'IgniteServicesProcessor'?

> And ServiceSingleDeploymentsResults name doesn't make sense to me.
> "Single deployments" doesn't sound right.

'Single' means 'single node', maybe we should use one of the following:
- 'ServicesSingleNodeDeploymentsResults'
- 'ServicesNodeDeploymentsResults'
- 'ServicesInstanceDeploymentsResults'

On Wed, Dec 19, 2018 at 4:26 PM Denis Mekhanikov <dm...@gmail.com> wrote:
>
> Slava,
> I think, it's better to replace word "Change" with "Request".
>
> Nik,
> We have IgniteServiceProcessor and GridServiceProcessor with singular
> "Service",
> ServicesDeploymentManager and ServicesDeploymentTask with plural "Services"
> for some reason.
> So, you need to remember, where Service and where Services is used.
> I think, we should unify these names.
> And ServiceSingleDeploymentsResults name doesn't make sense to me.
> "Single deployments" doesn't sound right.
>
> ServicesFullDeploymentsMessage is derived
> from GridDhtPartitionsFullMessage.
> It doesn't really reflect its function. This message is supposed to mark
> the point in time, when deployment is finished.
>
> Denis
>
>
> пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:
>
> > >*1. Testing of the cache-based implementation of the service grid.*
> > > I think, we should make a test suite, that will test the old
> > implementation
> > > until we remove it from the project.
> >
> > Agree. This is exactly what should be done as the first step once
> > phase 1 will be merged.
> > I think all tests in the package:
> > "org.apache.ignite.internal.processors.service" should be moved to
> > separate test-suite and new build-plan should be added on TC and
> > included in RunAll.
> >
> > > *2. DynamicServiceChangeRequest.*
> > > I think, this class should be splat into two.
> >
> > Personally, I agree, but I have faced opposition at the design step.
> > I changed to the following structure:
> >
> > abstract class ServiceAbstractChange implements Serializable {
> >     protected final IgniteUuid srvcId;
> > }
> >
> > class ServiceDeploymentChange extends ServiceAbstractChange {
> >     ServiceConfiguration cfg;
> > }
> >
> > class ServiceUndeploymentChange extends ServiceAbstractChange { }
> >
> > I hope that further reviewers will agree with us.
> >
> > > *3. Naming.*
> >
> > About "Services" -> "Service" and "Deployments" -> "Deployment"
> > Personally, I agree with Nikolay, because it's more descriptive since
> > manages several services, not single.
> > But, I understand Denis's point of view, we have a lot of classes with
> > "Service" prefix in naming and "Services" looks a bit alien.
> >
> > > *DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
> > Prefix "Dynamic" has no sense anymore since we reworked message
> > structure as in p.2. so "ServiceChangeBatchRequest" will be better
> > name.
> >
> > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > It's not a response and is not sent to the sender. This message is
> > sent to the coordinator and contains *single node* deployments.
> >
> > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > This should be named similar way as the previous one, but the message
> > contains deployments of *full set of nodes*.
> >
> >
> > On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <ni...@apache.org>
> > wrote:
> > >
> > > Hello, Denis.
> > >
> > > Great news.
> > >
> > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > I think, we should make a test suite, that will test the old
> > implementation> until we> remove it from the project.
> > >
> > > Aggree. Let's do it.
> > >
> > > > *2. DynamicServiceChangeRequest.*
> > > > I think, this class should be splat into two.
> > >
> > > Agree. Lets's do it.
> > >
> > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> > classes> with Services word in them.
> > > > I think, they would look better if we use a singular word *Service
> > *instead.
> > > > Same for *Deployments*.
> > >
> > > Personally, I want that names as clearly as possible reflects class
> > content for reader.
> > > If we deploy *several* services then it has to be Service*S*.
> > >
> > > Same for deployment - if this message will initiate single deployment
> > process then it should use deployment.
> > > otherwise - deployments.
> > >
> > > So my opinion - it's better to keep current naming.
> > >
> > > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > > Guys,
> > > >
> > > > I've been looking through the PR by Vyacheslav for past few weeks.
> > > > Slava, great job! You've done an impressive amount of work.
> > > >
> > > > I posted my comments to the PR and had a few calls with Slava.
> > > > I am close to finishing my review.
> > > > There are some points, that I'd like to settle in this discussion to
> > avoid
> > > > controversy.
> > > >
> > > > *1. Testing of the cache-based implementation of the service grid.*
> > > > I think, we should make a test suite, that will test the old
> > implementation
> > > > until we
> > > > remove it from the project.
> > > >
> > > > *2. DynamicServiceChangeRequest.*
> > > > I think, this class should be splat into two.
> > > > I don't see any point in having a single class with "*flags"* field,
> > that
> > > > shows, what action it actually represents.
> > > > Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)*
> > looks
> > > > wrong.
> > > > Why not have a separate message type for each action instead?
> > > >
> > > > *3. Naming.*
> > > > I suggest renaming the following classes:
> > > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> > classes
> > > > with Services word in them.
> > > > I think, they would look better if we use a singular word *Service
> > *instead.
> > > > Same for *Deployments*.
> > > > I propose the following class names:
> > > >
> > > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > > *ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*
> > > >
> > > > *DynamicServicesChangeRequestBatchMessage ->
> > DynamicServiceChangeRequest*
> > > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > > >
> > > > *ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
> > > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > > >
> > > > Let's do this as the final step of the code review to avoid repeated
> > > > renaming.
> > > >
> > > > Denis
> > > >
> > > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <dm...@gmail.com>:
> > > >
> > > > > Alexey,
> > > > >
> > > > > I don't see any problem in letting services work on a deactivated
> > cluster.
> > > > > All services need is discovery messages and compute tasks.
> > > > > Both of these features are available at all times.
> > > > >
> > > > > But it should be configurable. Services may need caches for their
> > work,
> > > > > so it's better to undeploy such services on cluster deactivation.
> > > > > We may introduce a new property in ServiceConfiguration.
> > > > >
> > > > > I think, this topic deserves a separate discussion.
> > > > > Could you start another thread?
> > > > >
> > > > > Denis
> > > > >
> > > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <akuznetsov@apache.org
> > >:
> > > > >
> > > > > > Hi,   Vyacheslav!
> > > > > >
> > > > > > I'm thinking about to use Services API to implement Web Agent as a
> > cluster
> > > > > > singleton service.
> > > > > > It will improve Web Console UX, because it will not needed to start
> > > > > > separate java program.
> > > > > > Just start cluster with Web agent enabled on cluster configuration.
> > > > > >
> > > > > > But in order to do this, I need that services should:
> > > > > >   1) Work when cluster NOT ACTIVE.
> > > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > > >
> > > > > > Could we support mentioned features on "Service Grid redesign -
> > phase 2" ?
> > > > > >
> > > > > > Please let me know.
> > > > > >
> > > > > > --
> > > > > > Alexey Kuznetsov
> > > > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Slava,
I think, it's better to replace word "Change" with "Request".

Nik,
We have IgniteServiceProcessor and GridServiceProcessor with singular
"Service",
ServicesDeploymentManager and ServicesDeploymentTask with plural "Services"
for some reason.
So, you need to remember, where Service and where Services is used.
I think, we should unify these names.
And ServiceSingleDeploymentsResults name doesn't make sense to me.
"Single deployments" doesn't sound right.

ServicesFullDeploymentsMessage is derived
from GridDhtPartitionsFullMessage.
It doesn't really reflect its function. This message is supposed to mark
the point in time, when deployment is finished.

Denis


пт, 14 дек. 2018 г. в 11:30, Vyacheslav Daradur <da...@gmail.com>:

> >*1. Testing of the cache-based implementation of the service grid.*
> > I think, we should make a test suite, that will test the old
> implementation
> > until we remove it from the project.
>
> Agree. This is exactly what should be done as the first step once
> phase 1 will be merged.
> I think all tests in the package:
> "org.apache.ignite.internal.processors.service" should be moved to
> separate test-suite and new build-plan should be added on TC and
> included in RunAll.
>
> > *2. DynamicServiceChangeRequest.*
> > I think, this class should be splat into two.
>
> Personally, I agree, but I have faced opposition at the design step.
> I changed to the following structure:
>
> abstract class ServiceAbstractChange implements Serializable {
>     protected final IgniteUuid srvcId;
> }
>
> class ServiceDeploymentChange extends ServiceAbstractChange {
>     ServiceConfiguration cfg;
> }
>
> class ServiceUndeploymentChange extends ServiceAbstractChange { }
>
> I hope that further reviewers will agree with us.
>
> > *3. Naming.*
>
> About "Services" -> "Service" and "Deployments" -> "Deployment"
> Personally, I agree with Nikolay, because it's more descriptive since
> manages several services, not single.
> But, I understand Denis's point of view, we have a lot of classes with
> "Service" prefix in naming and "Services" looks a bit alien.
>
> > *DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
> Prefix "Dynamic" has no sense anymore since we reworked message
> structure as in p.2. so "ServiceChangeBatchRequest" will be better
> name.
>
> > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> It's not a response and is not sent to the sender. This message is
> sent to the coordinator and contains *single node* deployments.
>
> > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> This should be named similar way as the previous one, but the message
> contains deployments of *full set of nodes*.
>
>
> On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
> >
> > Hello, Denis.
> >
> > Great news.
> >
> > > *1. Testing of the cache-based implementation of the service grid.*
> > > I think, we should make a test suite, that will test the old
> implementation> until we> remove it from the project.
> >
> > Aggree. Let's do it.
> >
> > > *2. DynamicServiceChangeRequest.*
> > > I think, this class should be splat into two.
> >
> > Agree. Lets's do it.
> >
> > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> classes> with Services word in them.
> > > I think, they would look better if we use a singular word *Service
> *instead.
> > > Same for *Deployments*.
> >
> > Personally, I want that names as clearly as possible reflects class
> content for reader.
> > If we deploy *several* services then it has to be Service*S*.
> >
> > Same for deployment - if this message will initiate single deployment
> process then it should use deployment.
> > otherwise - deployments.
> >
> > So my opinion - it's better to keep current naming.
> >
> > В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > > Guys,
> > >
> > > I've been looking through the PR by Vyacheslav for past few weeks.
> > > Slava, great job! You've done an impressive amount of work.
> > >
> > > I posted my comments to the PR and had a few calls with Slava.
> > > I am close to finishing my review.
> > > There are some points, that I'd like to settle in this discussion to
> avoid
> > > controversy.
> > >
> > > *1. Testing of the cache-based implementation of the service grid.*
> > > I think, we should make a test suite, that will test the old
> implementation
> > > until we
> > > remove it from the project.
> > >
> > > *2. DynamicServiceChangeRequest.*
> > > I think, this class should be splat into two.
> > > I don't see any point in having a single class with "*flags"* field,
> that
> > > shows, what action it actually represents.
> > > Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)*
> looks
> > > wrong.
> > > Why not have a separate message type for each action instead?
> > >
> > > *3. Naming.*
> > > I suggest renaming the following classes:
> > > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other
> classes
> > > with Services word in them.
> > > I think, they would look better if we use a singular word *Service
> *instead.
> > > Same for *Deployments*.
> > > I propose the following class names:
> > >
> > > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > > *ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*
> > >
> > > *DynamicServicesChangeRequestBatchMessage ->
> DynamicServiceChangeRequest*
> > > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> > >
> > > *ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
> > > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> > >
> > > Let's do this as the final step of the code review to avoid repeated
> > > renaming.
> > >
> > > Denis
> > >
> > > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <dm...@gmail.com>:
> > >
> > > > Alexey,
> > > >
> > > > I don't see any problem in letting services work on a deactivated
> cluster.
> > > > All services need is discovery messages and compute tasks.
> > > > Both of these features are available at all times.
> > > >
> > > > But it should be configurable. Services may need caches for their
> work,
> > > > so it's better to undeploy such services on cluster deactivation.
> > > > We may introduce a new property in ServiceConfiguration.
> > > >
> > > > I think, this topic deserves a separate discussion.
> > > > Could you start another thread?
> > > >
> > > > Denis
> > > >
> > > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <akuznetsov@apache.org
> >:
> > > >
> > > > > Hi,   Vyacheslav!
> > > > >
> > > > > I'm thinking about to use Services API to implement Web Agent as a
> cluster
> > > > > singleton service.
> > > > > It will improve Web Console UX, because it will not needed to start
> > > > > separate java program.
> > > > > Just start cluster with Web agent enabled on cluster configuration.
> > > > >
> > > > > But in order to do this, I need that services should:
> > > > >   1) Work when cluster NOT ACTIVE.
> > > > >   2) Auto restart with cluster (when cluster was restarted).
> > > > >
> > > > > Could we support mentioned features on "Service Grid redesign -
> phase 2" ?
> > > > >
> > > > > Please let me know.
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
>*1. Testing of the cache-based implementation of the service grid.*
> I think, we should make a test suite, that will test the old implementation
> until we remove it from the project.

Agree. This is exactly what should be done as the first step once
phase 1 will be merged.
I think all tests in the package:
"org.apache.ignite.internal.processors.service" should be moved to
separate test-suite and new build-plan should be added on TC and
included in RunAll.

> *2. DynamicServiceChangeRequest.*
> I think, this class should be splat into two.

Personally, I agree, but I have faced opposition at the design step.
I changed to the following structure:

abstract class ServiceAbstractChange implements Serializable {
    protected final IgniteUuid srvcId;
}

class ServiceDeploymentChange extends ServiceAbstractChange {
    ServiceConfiguration cfg;
}

class ServiceUndeploymentChange extends ServiceAbstractChange { }

I hope that further reviewers will agree with us.

> *3. Naming.*

About "Services" -> "Service" and "Deployments" -> "Deployment"
Personally, I agree with Nikolay, because it's more descriptive since
manages several services, not single.
But, I understand Denis's point of view, we have a lot of classes with
"Service" prefix in naming and "Services" looks a bit alien.

> *DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
Prefix "Dynamic" has no sense anymore since we reworked message
structure as in p.2. so "ServiceChangeBatchRequest" will be better
name.

> *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
It's not a response and is not sent to the sender. This message is
sent to the coordinator and contains *single node* deployments.

> *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
This should be named similar way as the previous one, but the message
contains deployments of *full set of nodes*.


On Fri, Dec 14, 2018 at 10:58 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> Hello, Denis.
>
> Great news.
>
> > *1. Testing of the cache-based implementation of the service grid.*
> > I think, we should make a test suite, that will test the old implementation> until we> remove it from the project.
>
> Aggree. Let's do it.
>
> > *2. DynamicServiceChangeRequest.*
> > I think, this class should be splat into two.
>
> Agree. Lets's do it.
>
> > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other classes> with Services word in them.
> > I think, they would look better if we use a singular word *Service *instead.
> > Same for *Deployments*.
>
> Personally, I want that names as clearly as possible reflects class content for reader.
> If we deploy *several* services then it has to be Service*S*.
>
> Same for deployment - if this message will initiate single deployment process then it should use deployment.
> otherwise - deployments.
>
> So my opinion - it's better to keep current naming.
>
> В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> > Guys,
> >
> > I've been looking through the PR by Vyacheslav for past few weeks.
> > Slava, great job! You've done an impressive amount of work.
> >
> > I posted my comments to the PR and had a few calls with Slava.
> > I am close to finishing my review.
> > There are some points, that I'd like to settle in this discussion to avoid
> > controversy.
> >
> > *1. Testing of the cache-based implementation of the service grid.*
> > I think, we should make a test suite, that will test the old implementation
> > until we
> > remove it from the project.
> >
> > *2. DynamicServiceChangeRequest.*
> > I think, this class should be splat into two.
> > I don't see any point in having a single class with "*flags"* field, that
> > shows, what action it actually represents.
> > Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)* looks
> > wrong.
> > Why not have a separate message type for each action instead?
> >
> > *3. Naming.*
> > I suggest renaming the following classes:
> > *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other classes
> > with Services word in them.
> > I think, they would look better if we use a singular word *Service *instead.
> > Same for *Deployments*.
> > I propose the following class names:
> >
> > *ServicesDeploymentManager -> ServiceDeploymentManager*
> > *ServicesDeploymentActions -> ServiceDeploymentActions*
> > *ServicesDeploymentTask -> ServiceDeploymentTask*
> > *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> > *ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*
> >
> > *DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
> > *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> > *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> >
> > *ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
> > *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> >
> > Let's do this as the final step of the code review to avoid repeated
> > renaming.
> >
> > Denis
> >
> > чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <dm...@gmail.com>:
> >
> > > Alexey,
> > >
> > > I don't see any problem in letting services work on a deactivated cluster.
> > > All services need is discovery messages and compute tasks.
> > > Both of these features are available at all times.
> > >
> > > But it should be configurable. Services may need caches for their work,
> > > so it's better to undeploy such services on cluster deactivation.
> > > We may introduce a new property in ServiceConfiguration.
> > >
> > > I think, this topic deserves a separate discussion.
> > > Could you start another thread?
> > >
> > > Denis
> > >
> > > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <ak...@apache.org>:
> > >
> > > > Hi,   Vyacheslav!
> > > >
> > > > I'm thinking about to use Services API to implement Web Agent as a cluster
> > > > singleton service.
> > > > It will improve Web Console UX, because it will not needed to start
> > > > separate java program.
> > > > Just start cluster with Web agent enabled on cluster configuration.
> > > >
> > > > But in order to do this, I need that services should:
> > > >   1) Work when cluster NOT ACTIVE.
> > > >   2) Auto restart with cluster (when cluster was restarted).
> > > >
> > > > Could we support mentioned features on "Service Grid redesign - phase 2" ?
> > > >
> > > > Please let me know.
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >



--
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Denis.

Great news.

> *1. Testing of the cache-based implementation of the service grid.*
> I think, we should make a test suite, that will test the old implementation> until we> remove it from the project.

Aggree. Let's do it.

> *2. DynamicServiceChangeRequest.*
> I think, this class should be splat into two.

Agree. Lets's do it.

> *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other classes> with Services word in them.
> I think, they would look better if we use a singular word *Service *instead.
> Same for *Deployments*.

Personally, I want that names as clearly as possible reflects class content for reader.
If we deploy *several* services then it has to be Service*S*.

Same for deployment - if this message will initiate single deployment process then it should use deployment.
otherwise - deployments.

So my opinion - it's better to keep current naming.

В Чт, 13/12/2018 в 19:36 +0300, Denis Mekhanikov пишет:
> Guys,
> 
> I've been looking through the PR by Vyacheslav for past few weeks.
> Slava, great job! You've done an impressive amount of work.
> 
> I posted my comments to the PR and had a few calls with Slava.
> I am close to finishing my review.
> There are some points, that I'd like to settle in this discussion to avoid
> controversy.
> 
> *1. Testing of the cache-based implementation of the service grid.*
> I think, we should make a test suite, that will test the old implementation
> until we
> remove it from the project.
> 
> *2. DynamicServiceChangeRequest.*
> I think, this class should be splat into two.
> I don't see any point in having a single class with "*flags"* field, that
> shows, what action it actually represents.
> Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)* looks
> wrong.
> Why not have a separate message type for each action instead?
> 
> *3. Naming.*
> I suggest renaming the following classes:
> *ServicesDeploymentManager*, *ServicesDeploymentTask *and all other classes
> with Services word in them.
> I think, they would look better if we use a singular word *Service *instead.
> Same for *Deployments*.
> I propose the following class names:
> 
> *ServicesDeploymentManager -> ServiceDeploymentManager*
> *ServicesDeploymentActions -> ServiceDeploymentActions*
> *ServicesDeploymentTask -> ServiceDeploymentTask*
> *ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
> *ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*
> 
> *DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
> *ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
> *ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*
> 
> *ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
> *ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*
> 
> Let's do this as the final step of the code review to avoid repeated
> renaming.
> 
> Denis
> 
> чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <dm...@gmail.com>:
> 
> > Alexey,
> > 
> > I don't see any problem in letting services work on a deactivated cluster.
> > All services need is discovery messages and compute tasks.
> > Both of these features are available at all times.
> > 
> > But it should be configurable. Services may need caches for their work,
> > so it's better to undeploy such services on cluster deactivation.
> > We may introduce a new property in ServiceConfiguration.
> > 
> > I think, this topic deserves a separate discussion.
> > Could you start another thread?
> > 
> > Denis
> > 
> > чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <ak...@apache.org>:
> > 
> > > Hi,   Vyacheslav!
> > > 
> > > I'm thinking about to use Services API to implement Web Agent as a cluster
> > > singleton service.
> > > It will improve Web Console UX, because it will not needed to start
> > > separate java program.
> > > Just start cluster with Web agent enabled on cluster configuration.
> > > 
> > > But in order to do this, I need that services should:
> > >   1) Work when cluster NOT ACTIVE.
> > >   2) Auto restart with cluster (when cluster was restarted).
> > > 
> > > Could we support mentioned features on "Service Grid redesign - phase 2" ?
> > > 
> > > Please let me know.
> > > 
> > > --
> > > Alexey Kuznetsov
> > >

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Guys,

I've been looking through the PR by Vyacheslav for past few weeks.
Slava, great job! You've done an impressive amount of work.

I posted my comments to the PR and had a few calls with Slava.
I am close to finishing my review.
There are some points, that I'd like to settle in this discussion to avoid
controversy.

*1. Testing of the cache-based implementation of the service grid.*
I think, we should make a test suite, that will test the old implementation
until we
remove it from the project.

*2. DynamicServiceChangeRequest.*
I think, this class should be splat into two.
I don't see any point in having a single class with "*flags"* field, that
shows, what action it actually represents.
Usage of *deploy(), markDeploy(...), undeploy(), markUndeploy(...)* looks
wrong.
Why not have a separate message type for each action instead?

*3. Naming.*
I suggest renaming the following classes:
*ServicesDeploymentManager*, *ServicesDeploymentTask *and all other classes
with Services word in them.
I think, they would look better if we use a singular word *Service *instead.
Same for *Deployments*.
I propose the following class names:

*ServicesDeploymentManager -> ServiceDeploymentManager*
*ServicesDeploymentActions -> ServiceDeploymentActions*
*ServicesDeploymentTask -> ServiceDeploymentTask*
*ServicesCommonDiscoveryData -> ServiceCommonDiscoveryData*
*ServicesJoinNodeDiscoveryData -> ServiceJoiningNodeDiscoveryData*

*DynamicServicesChangeRequestBatchMessage -> DynamicServiceChangeRequest*
*ServicesSingleDeploymentsMessage -> ServiceDeploymentResponse*
*ServicesFullDeploymentsMessage -> ServiceDeploymentFinishMessage*

*ServiceSingleDeploymentsResults -> ServiceSingleDeploymentResult*
*ServiceFullDeploymentsResults -> ServiceFullDeploymentResult*

Let's do this as the final step of the code review to avoid repeated
renaming.

Denis

чт, 6 дек. 2018 г. в 15:21, Denis Mekhanikov <dm...@gmail.com>:

> Alexey,
>
> I don't see any problem in letting services work on a deactivated cluster.
> All services need is discovery messages and compute tasks.
> Both of these features are available at all times.
>
> But it should be configurable. Services may need caches for their work,
> so it's better to undeploy such services on cluster deactivation.
> We may introduce a new property in ServiceConfiguration.
>
> I think, this topic deserves a separate discussion.
> Could you start another thread?
>
> Denis
>
> чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <ak...@apache.org>:
>
>> Hi,   Vyacheslav!
>>
>> I'm thinking about to use Services API to implement Web Agent as a cluster
>> singleton service.
>> It will improve Web Console UX, because it will not needed to start
>> separate java program.
>> Just start cluster with Web agent enabled on cluster configuration.
>>
>> But in order to do this, I need that services should:
>>   1) Work when cluster NOT ACTIVE.
>>   2) Auto restart with cluster (when cluster was restarted).
>>
>> Could we support mentioned features on "Service Grid redesign - phase 2" ?
>>
>> Please let me know.
>>
>> --
>> Alexey Kuznetsov
>>
>

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Alexey,

I don't see any problem in letting services work on a deactivated cluster.
All services need is discovery messages and compute tasks.
Both of these features are available at all times.

But it should be configurable. Services may need caches for their work,
so it's better to undeploy such services on cluster deactivation.
We may introduce a new property in ServiceConfiguration.

I think, this topic deserves a separate discussion.
Could you start another thread?

Denis

чт, 6 дек. 2018 г. в 13:27, Alexey Kuznetsov <ak...@apache.org>:

> Hi,   Vyacheslav!
>
> I'm thinking about to use Services API to implement Web Agent as a cluster
> singleton service.
> It will improve Web Console UX, because it will not needed to start
> separate java program.
> Just start cluster with Web agent enabled on cluster configuration.
>
> But in order to do this, I need that services should:
>   1) Work when cluster NOT ACTIVE.
>   2) Auto restart with cluster (when cluster was restarted).
>
> Could we support mentioned features on "Service Grid redesign - phase 2" ?
>
> Please let me know.
>
> --
> Alexey Kuznetsov
>

Re: Service grid redesign

Posted by Alexey Kuznetsov <ak...@apache.org>.
Hi,   Vyacheslav!

I'm thinking about to use Services API to implement Web Agent as a cluster
singleton service.
It will improve Web Console UX, because it will not needed to start
separate java program.
Just start cluster with Web agent enabled on cluster configuration.

But in order to do this, I need that services should:
  1) Work when cluster NOT ACTIVE.
  2) Auto restart with cluster (when cluster was restarted).

Could we support mentioned features on "Service Grid redesign - phase 2" ?

Please let me know.

-- 
Alexey Kuznetsov

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Hi, Igniters!

I fixed the notes and tests seem good.

So, let's continue the review [1] [2], any feedback is welcome!

[1] https://github.com/apache/ignite/pull/4434
[2] https://issues.apache.org/jira/browse/IGNITE-9607
On Tue, Nov 27, 2018 at 5:16 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> We had the private talk with Nikolay Izhikov, Vladimir Ozerov, Alexey
> Goncharuk, Yakov Zhdanov, Denis Mekhanikov, Dmitriy Pavlov and I would
> like to share the summary with the community:
>
> The architecture of the implemented deployment process looks good in
> general, but the following points should be improved:
> * The new implementation of service processor implementation should be
> moved to a new class;
> * A new system property should be introduced to allow users to switch
> to old implementation in case of errors;
> * Introduced service deployment failures policy should be removed from
> current PR and should be implemented as a different task with detailed
> discussion on dev list to avoid unexpected behavior;
> * The word "exchange" should be removed from classes names to avoid
> confusion with PME classes.
> * Single/full messages should include containing only deployment
> process-related information only (instead of all service) to reduce
> messages size;
>
> Thanks all! I'll let you know once I fix the notes.
>
> On Wed, Nov 21, 2018 at 4:28 PM Dmitriy Pavlov <dp...@apache.org> wrote:
> >
> > Hi Vyacheslav, Vladimir,
> >
> > Could you please invite me, if you will set up a call.
> >
> > ср, 21 нояб. 2018 г. в 13:08, Vladimir Ozerov <vo...@gridgain.com>:
> >
> > > Hi Vyacheslav,
> > >
> > > Still not clear enough for me. I do not see a reason to send another over a
> > > ring in case of successful execution. The only reason is an error on a node
> > > which require correction (re-deploy to other node, full service undeploy,
> > > etc).
> > > I think it makes sense to organize another call to discuss current
> > > architecture. Otherwise we may spend too much time on emails.
> > >
> > > Vladimir.
> > >
> > > On Wed, Nov 21, 2018 at 12:57 PM Vyacheslav Daradur <da...@gmail.com>
> > > wrote:
> > >
> > > > The full map is needed:
> > > > 1) to propagate deployment results which could be different from
> > > > locally calculated in case of any errors;
> > > > 2) to transfer deployment errors across the cluster;
> > > > 3) to undeploy exceeded the number of service instances if needed;
> > > > 4) to get know other nodes that deployment process was finished, this
> > > > need to avoid calling services which have not been deployed yet (or
> > > > can't be deployed). We can't just store pending requests because of
> > > > time to deploy one service instances which may be significant.
> > > > On Wed, Nov 21, 2018 at 12:45 PM Vladimir Ozerov <vo...@gridgain.com>
> > > > wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > I looked at the document and failed to find explanation why full maps
> > > are
> > > > > needed. Could you point me to a place where it is explained?
> > > > > I ask this because my impression from last discussion was that it is
> > > > never
> > > > > needed. Service status change is initiated by user action, then all
> > > nodes
> > > > > perform respective action locally, then they reply to coordinator, then
> > > > > coordinator reply to the client, no need a kind of "full" map over
> > > > > discovery again. The only situation when another message over ring is
> > > > > required, is when some node failed to execute local operation (for
> > > > whatever
> > > > > reason) and corrective action is required.
> > > > >
> > > > > Am I missing something?
> > > > >
> > > > > On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <
> > > daradurvs@gmail.com
> > > > >
> > > > > wrote:
> > > > >
> > > > > > Denis, I suggested new names above in the thread.
> > > > > >
> > > > > > Please, look at PME document [1] is should be quiet actual to show
> > > the
> > > > > > same flow.
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <
> > > > dmekhanikov@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > Actually, the service assignment is implemented in a way,
> > > > > > > that allows every node calculate the assignment itself, so no
> > > > information
> > > > > > > needs to be shared.
> > > > > > > The only data, that is sent between nodes is deployment results,
> > > > > > > and I don't see an analogy with exchange here.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <
> > > vozerov@gridgain.com
> > > > >:
> > > > > > >
> > > > > > > > Hi Vyacheslav,
> > > > > > > >
> > > > > > > > Could you please explain in what situation coordinator needs to
> > > > collect
> > > > > > > > service deployments info from all nodes and share it with the
> > > > cluster?
> > > > > > I
> > > > > > > > cannot remember from our design discussion when it is needed.
> > > > Global
> > > > > > state
> > > > > > > > normally shared through discovery and only on node join, In this
> > > > case
> > > > > > we
> > > > > > > > use "DiscoveryDataBags", not separate messages.
> > > > > > > >
> > > > > > > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I think request-response is not suitable terms.
> > > > > > > > >
> > > > > > > > > Nodes send to coordinator maps of actual service deployments
> > > > which
> > > > > > > > > contains what count of instances of each service node hosts
> > > > locally.
> > > > > > > > >
> > > > > > > > > Coordinator sends to the cluster the full map of deployments
> > > > across
> > > > > > the
> > > > > > > > > cluster.
> > > > > > > > >
> > > > > > > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> > > > > > vozerov@gridgain.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > I do not know what is correct term :-) What I said is that
> > > > > > "exchange"
> > > > > > > > is
> > > > > > > > > > counter intuitive here. There is no "exchange", instead nodes
> > > > send
> > > > > > > > > > information to coordinator that they finished some operation.
> > > > E.g.
> > > > > > we
> > > > > > > > do
> > > > > > > > > > the same for schema changes (index creation), and as Denis
> > > > > > suggested,
> > > > > > > > > > Request-Response is correct suffixes here. Message name
> > > should
> > > > > > explain
> > > > > > > > > what
> > > > > > > > > > really happened, instead of describing things which are
> > > > somewhat
> > > > > > > > similar
> > > > > > > > > in
> > > > > > > > > > internal flow.
> > > > > > > > > >
> > > > > > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> > > > > > nizhikov@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > >
> > > > > > > > > > > What is correct term?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov
> > > > vozerov@gridgain.com
> > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > Agree. Service deployment has nothing to do with PME. We
> > > > > > should not
> > > > > > > > > use
> > > > > > > > > > > the
> > > > > > > > > > > > same term for different things.
> > > > > > > > > > > >
> > > > > > > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > > >
> > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm in process of reviewing your changes. Sorry for
> > > > taking so
> > > > > > > > long.
> > > > > > > > > > > > > I posted the first portion of review comments
> > > yesterday.
> > > > > > > > > > > > > I'd like to finish looking through the code. I'll post
> > > > more
> > > > > > > > > comments
> > > > > > > > > > > > later.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I see, that you called things analogously to partition
> > > > map
> > > > > > > > > exchange.
> > > > > > > > > > > > > I realize, that there is an analogy in used procedures,
> > > > but I
> > > > > > > > don't
> > > > > > > > > > > > really
> > > > > > > > > > > > > like the idea to use the same names for everything.
> > > > > > > > > > > > > The partition map exchange is called this way because
> > > it
> > > > > > involves
> > > > > > > > > an
> > > > > > > > > > > > actual
> > > > > > > > > > > > > exchange of information.
> > > > > > > > > > > > > All nodes need to tell each other, which partitions
> > > they
> > > > > > have,
> > > > > > > > and
> > > > > > > > > what
> > > > > > > > > > > > > their states are.
> > > > > > > > > > > > >
> > > > > > > > > > > > > There is no exchange in case of service deployment, so
> > > I
> > > > > > would
> > > > > > > > > skip the
> > > > > > > > > > > > > "exchange" part.
> > > > > > > > > > > > > And *single message ->* *full message* look more like
> > > > > > *request ->
> > > > > > > > > > > > response*
> > > > > > > > > > > > > in case of services.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Suppose we abandon the PME procedure and move to
> > > > something
> > > > > > else.
> > > > > > > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > > > > > > And I don't want to be in a situation, when I say to my
> > > > > > > > colleague a
> > > > > > > > > > > word
> > > > > > > > > > > > > "exchange",
> > > > > > > > > > > > > and get "which one?" in return.
> > > > > > > > > > > > > So, I'm for the meaningful names rather than analogous
> > > to
> > > > > > > > something
> > > > > > > > > > > else.
> > > > > > > > > > > > >
> > > > > > > > > > > > > What do you think?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis, Yakov have you had a chance to review the
> > > > solution?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Igniters, we need to define a list of reviewers,
> > > > otherwise
> > > > > > no
> > > > > > > > > end in
> > > > > > > > > > > > > sign.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm ready to continue work on the Service Grid,
> > > > including
> > > > > > new
> > > > > > > > > > > features
> > > > > > > > > > > > > > like hot-redeployment and versioning, also, I have
> > > > ideas
> > > > > > about
> > > > > > > > > new
> > > > > > > > > > > > > > tools for monitoring and management which will be
> > > > useful
> > > > > > for
> > > > > > > > our
> > > > > > > > > > > > > > end-users.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But for continuing work we need to overcome this
> > > first
> > > > > > phase.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis, Yakov, feel free to contact me directly in
> > > > case of
> > > > > > > > > > > questions.
> > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'd like to take a look at the changes before
> > > they
> > > > are
> > > > > > > > > merged.
> > > > > > > > > > > > > > > > I'll do my best to finish the review before the
> > > > end of
> > > > > > the
> > > > > > > > > > > upcoming
> > > > > > > > > > > > > > week.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > > > > > > nizhikov@apache.org
> > > > > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Can we write the list of reviewers for this
> > > > feature?
> > > > > > > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > > > > > > Just a list of experts who should review this
> > > > > > feature.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> > > > > > пишет:
> > > > > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This is very huge thing with complex
> > > algorithms
> > > > > > behind.
> > > > > > > > > We
> > > > > > > > > > > > should
> > > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > > merge
> > > > > > > > > > > > > > > > > > it to the product unless several additional
> > > > > > thorough
> > > > > > > > > reviews
> > > > > > > > > > > > are
> > > > > > > > > > > > > > ready,
> > > > > > > > > > > > > > > > > > irrespectively of how long will it take. We
> > > are
> > > > > > about
> > > > > > > > > > > quality,
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > speed.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > > > > > > dmagda@apache.org
> > > > > > > > > > > >:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > What are the cases when the service can be
> > > > > > > > redeployed?
> > > > > > > > > > > > > Affinity,
> > > > > > > > > > > > > > > > > failure,
> > > > > > > > > > > > > > > > > > > etc., right. It would be good to list all
> > > the
> > > > > > cases
> > > > > > > > on
> > > > > > > > > the
> > > > > > > > > > > > wiki
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > then
> > > > > > > > > > > > > > > > > > > our tech writers will get everything
> > > > documented.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> > > > > > Daradur <
> > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Services reassignment process takes into
> > > > > > account
> > > > > > > > > previous
> > > > > > > > > > > > > > assignments
> > > > > > > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > > > > > > So, in the described case, ServiceA won't
> > > > be
> > > > > > moved
> > > > > > > > > from
> > > > > > > > > > > > node1
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis
> > > Magda
> > > > <
> > > > > > > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > First of all, thanks for archiving this
> > > > > > milestone
> > > > > > > > > and
> > > > > > > > > > > > > > rolling out
> > > > > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Speaking of the topology change events
> > > > [1],
> > > > > > does
> > > > > > > > > the
> > > > > > > > > > > new
> > > > > > > > > > > > > > > > > architecture
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > > > > > a running service redeployment when a
> > > new
> > > > > > node
> > > > > > > > > joins?
> > > > > > > > > > > For
> > > > > > > > > > > > > > instance,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > > > > > > say I have ServiceA running node1, then
> > > > node2
> > > > > > > > joins
> > > > > > > > > > > and I
> > > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > > service to be redeployed to any other
> > > > node.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM
> > > Vyacheslav
> > > > > > > > Daradur <
> > > > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Dmitriy, I published documentation in
> > > > wiki:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM
> > > Dmitriy
> > > > > > Pavlov <
> > > > > > > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> > > > > > attached
> > > > > > > > > docs.
> > > > > > > > > > > > Could
> > > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39
> > > Vyacheslav
> > > > > > > > Daradur <
> > > > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I prepared a description of the
> > > > > > implemented
> > > > > > > > > > > > solution
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > attached
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > This should help during a review.
> > > > > > Should I
> > > > > > > > > post
> > > > > > > > > > > the
> > > > > > > > > > > > > > document
> > > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> > > > > > review the
> > > > > > > > > > > > solution
> > > > > > > > > > > > > > [1] [2],
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> > > > > > Vyacheslav
> > > > > > > > > > > Daradur
> > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 -
> > > > is in
> > > > > > > > Patch
> > > > > > > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > > > > > > implementation.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > However, we need additional
> > > > review
> > > > > > from
> > > > > > > > > other
> > > > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1]
> > > > and PR
> > > > > > > > [2].
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Could someone step in and do
> > > the
> > > > > > review?
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44
> > > AM
> > > > > > Denis
> > > > > > > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net
> > > to
> > > > > > specify
> > > > > > > > > > > service
> > > > > > > > > > > > > > class name
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a
> > > > problem.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> > > > > > Vyacheslav
> > > > > > > > > > > Daradur
> > > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > I think that the
> > > replacement
> > > > of
> > > > > > > > > serialized
> > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > makes
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > But how it should work for
> > > > .NET
> > > > > > > > client?
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> > > 4:07
> > > > PM
> > > > > > > > Dmitriy
> > > > > > > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> > > > 6:10
> > > > > > AM,
> > > > > > > > > Nikita
> > > > > > > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I am working on task
> > > [1]
> > > > that
> > > > > > > > would
> > > > > > > > > > > > replace
> > > > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > by service's class name
> > > > and
> > > > > > > > > properties
> > > > > > > > > > > > map
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > The task describes that
> > > > we
> > > > > > should
> > > > > > > > > use
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> > > > > > {Map<String,
> > > > > > > > > > > Object>
> > > > > > > > > > > > > > > > > properties}
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> > > > > > following
> > > > > > > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. What about public
> > > > methods?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them
> > > as
> > > > > > > > > deprecated
> > > > > > > > > > > and
> > > > > > > > > > > > > use
> > > > > > > > > > > > > > class
> > > > > > > > > > > > > > > > > name
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying
> > > > methods
> > > > > > > > with
> > > > > > > > > new
> > > > > > > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > > srvcClsName,
> > > > > > > > > Map<String,
> > > > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I think this makes sense,
> > > > but I
> > > > > > > > would
> > > > > > > > > > > like
> > > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov
> > > > should
> > > > > > > > > comment
> > > > > > > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String,
> > > > Object>
> > > > > > > > > properties}
> > > > > > > > > > > > > > parameter
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> > > > > > deploying
> > > > > > > > > > > methods
> > > > > > > > > > > > > > without
> > > > > > > > > > > > > > > > > it?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > > srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > > srvcClsName,
> > > > > > > > > Map<String,
> > > > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I would always ask the
> > > > user to
> > > > > > pass
> > > > > > > > > the
> > > > > > > > > > > > > > property
> > > > > > > > > > > > > > > > > map, but
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
We had the private talk with Nikolay Izhikov, Vladimir Ozerov, Alexey
Goncharuk, Yakov Zhdanov, Denis Mekhanikov, Dmitriy Pavlov and I would
like to share the summary with the community:

The architecture of the implemented deployment process looks good in
general, but the following points should be improved:
* The new implementation of service processor implementation should be
moved to a new class;
* A new system property should be introduced to allow users to switch
to old implementation in case of errors;
* Introduced service deployment failures policy should be removed from
current PR and should be implemented as a different task with detailed
discussion on dev list to avoid unexpected behavior;
* The word "exchange" should be removed from classes names to avoid
confusion with PME classes.
* Single/full messages should include containing only deployment
process-related information only (instead of all service) to reduce
messages size;

Thanks all! I'll let you know once I fix the notes.

On Wed, Nov 21, 2018 at 4:28 PM Dmitriy Pavlov <dp...@apache.org> wrote:
>
> Hi Vyacheslav, Vladimir,
>
> Could you please invite me, if you will set up a call.
>
> ср, 21 нояб. 2018 г. в 13:08, Vladimir Ozerov <vo...@gridgain.com>:
>
> > Hi Vyacheslav,
> >
> > Still not clear enough for me. I do not see a reason to send another over a
> > ring in case of successful execution. The only reason is an error on a node
> > which require correction (re-deploy to other node, full service undeploy,
> > etc).
> > I think it makes sense to organize another call to discuss current
> > architecture. Otherwise we may spend too much time on emails.
> >
> > Vladimir.
> >
> > On Wed, Nov 21, 2018 at 12:57 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> >
> > > The full map is needed:
> > > 1) to propagate deployment results which could be different from
> > > locally calculated in case of any errors;
> > > 2) to transfer deployment errors across the cluster;
> > > 3) to undeploy exceeded the number of service instances if needed;
> > > 4) to get know other nodes that deployment process was finished, this
> > > need to avoid calling services which have not been deployed yet (or
> > > can't be deployed). We can't just store pending requests because of
> > > time to deploy one service instances which may be significant.
> > > On Wed, Nov 21, 2018 at 12:45 PM Vladimir Ozerov <vo...@gridgain.com>
> > > wrote:
> > > >
> > > > Vyacheslav,
> > > >
> > > > I looked at the document and failed to find explanation why full maps
> > are
> > > > needed. Could you point me to a place where it is explained?
> > > > I ask this because my impression from last discussion was that it is
> > > never
> > > > needed. Service status change is initiated by user action, then all
> > nodes
> > > > perform respective action locally, then they reply to coordinator, then
> > > > coordinator reply to the client, no need a kind of "full" map over
> > > > discovery again. The only situation when another message over ring is
> > > > required, is when some node failed to execute local operation (for
> > > whatever
> > > > reason) and corrective action is required.
> > > >
> > > > Am I missing something?
> > > >
> > > > On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Denis, I suggested new names above in the thread.
> > > > >
> > > > > Please, look at PME document [1] is should be quiet actual to show
> > the
> > > > > same flow.
> > > > >
> > > > > [1]
> > > > >
> > >
> > https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
> > > > >
> > > > > On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > Actually, the service assignment is implemented in a way,
> > > > > > that allows every node calculate the assignment itself, so no
> > > information
> > > > > > needs to be shared.
> > > > > > The only data, that is sent between nodes is deployment results,
> > > > > > and I don't see an analogy with exchange here.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <
> > vozerov@gridgain.com
> > > >:
> > > > > >
> > > > > > > Hi Vyacheslav,
> > > > > > >
> > > > > > > Could you please explain in what situation coordinator needs to
> > > collect
> > > > > > > service deployments info from all nodes and share it with the
> > > cluster?
> > > > > I
> > > > > > > cannot remember from our design discussion when it is needed.
> > > Global
> > > > > state
> > > > > > > normally shared through discovery and only on node join, In this
> > > case
> > > > > we
> > > > > > > use "DiscoveryDataBags", not separate messages.
> > > > > > >
> > > > > > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I think request-response is not suitable terms.
> > > > > > > >
> > > > > > > > Nodes send to coordinator maps of actual service deployments
> > > which
> > > > > > > > contains what count of instances of each service node hosts
> > > locally.
> > > > > > > >
> > > > > > > > Coordinator sends to the cluster the full map of deployments
> > > across
> > > > > the
> > > > > > > > cluster.
> > > > > > > >
> > > > > > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> > > > > vozerov@gridgain.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > I do not know what is correct term :-) What I said is that
> > > > > "exchange"
> > > > > > > is
> > > > > > > > > counter intuitive here. There is no "exchange", instead nodes
> > > send
> > > > > > > > > information to coordinator that they finished some operation.
> > > E.g.
> > > > > we
> > > > > > > do
> > > > > > > > > the same for schema changes (index creation), and as Denis
> > > > > suggested,
> > > > > > > > > Request-Response is correct suffixes here. Message name
> > should
> > > > > explain
> > > > > > > > what
> > > > > > > > > really happened, instead of describing things which are
> > > somewhat
> > > > > > > similar
> > > > > > > > in
> > > > > > > > > internal flow.
> > > > > > > > >
> > > > > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> > > > > nizhikov@apache.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello, Vladimir.
> > > > > > > > > >
> > > > > > > > > > What is correct term?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov
> > > vozerov@gridgain.com
> > > > > :
> > > > > > > > > >
> > > > > > > > > > > Agree. Service deployment has nothing to do with PME. We
> > > > > should not
> > > > > > > > use
> > > > > > > > > > the
> > > > > > > > > > > same term for different things.
> > > > > > > > > > >
> > > > > > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > > >
> > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > >
> > > > > > > > > > > > I'm in process of reviewing your changes. Sorry for
> > > taking so
> > > > > > > long.
> > > > > > > > > > > > I posted the first portion of review comments
> > yesterday.
> > > > > > > > > > > > I'd like to finish looking through the code. I'll post
> > > more
> > > > > > > > comments
> > > > > > > > > > > later.
> > > > > > > > > > > >
> > > > > > > > > > > > I see, that you called things analogously to partition
> > > map
> > > > > > > > exchange.
> > > > > > > > > > > > I realize, that there is an analogy in used procedures,
> > > but I
> > > > > > > don't
> > > > > > > > > > > really
> > > > > > > > > > > > like the idea to use the same names for everything.
> > > > > > > > > > > > The partition map exchange is called this way because
> > it
> > > > > involves
> > > > > > > > an
> > > > > > > > > > > actual
> > > > > > > > > > > > exchange of information.
> > > > > > > > > > > > All nodes need to tell each other, which partitions
> > they
> > > > > have,
> > > > > > > and
> > > > > > > > what
> > > > > > > > > > > > their states are.
> > > > > > > > > > > >
> > > > > > > > > > > > There is no exchange in case of service deployment, so
> > I
> > > > > would
> > > > > > > > skip the
> > > > > > > > > > > > "exchange" part.
> > > > > > > > > > > > And *single message ->* *full message* look more like
> > > > > *request ->
> > > > > > > > > > > response*
> > > > > > > > > > > > in case of services.
> > > > > > > > > > > >
> > > > > > > > > > > > Suppose we abandon the PME procedure and move to
> > > something
> > > > > else.
> > > > > > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > > > > > And I don't want to be in a situation, when I say to my
> > > > > > > colleague a
> > > > > > > > > > word
> > > > > > > > > > > > "exchange",
> > > > > > > > > > > > and get "which one?" in return.
> > > > > > > > > > > > So, I'm for the meaningful names rather than analogous
> > to
> > > > > > > something
> > > > > > > > > > else.
> > > > > > > > > > > >
> > > > > > > > > > > > What do you think?
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > > > > > daradurvs@gmail.com
> > > > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Denis, Yakov have you had a chance to review the
> > > solution?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Igniters, we need to define a list of reviewers,
> > > otherwise
> > > > > no
> > > > > > > > end in
> > > > > > > > > > > > sign.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm ready to continue work on the Service Grid,
> > > including
> > > > > new
> > > > > > > > > > features
> > > > > > > > > > > > > like hot-redeployment and versioning, also, I have
> > > ideas
> > > > > about
> > > > > > > > new
> > > > > > > > > > > > > tools for monitoring and management which will be
> > > useful
> > > > > for
> > > > > > > our
> > > > > > > > > > > > > end-users.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But for continuing work we need to overcome this
> > first
> > > > > phase.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis, Yakov, feel free to contact me directly in
> > > case of
> > > > > > > > > > questions.
> > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'd like to take a look at the changes before
> > they
> > > are
> > > > > > > > merged.
> > > > > > > > > > > > > > > I'll do my best to finish the review before the
> > > end of
> > > > > the
> > > > > > > > > > upcoming
> > > > > > > > > > > > > week.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > > > > > nizhikov@apache.org
> > > > > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Can we write the list of reviewers for this
> > > feature?
> > > > > > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > > > > > Just a list of experts who should review this
> > > > > feature.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> > > > > пишет:
> > > > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This is very huge thing with complex
> > algorithms
> > > > > behind.
> > > > > > > > We
> > > > > > > > > > > should
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > merge
> > > > > > > > > > > > > > > > > it to the product unless several additional
> > > > > thorough
> > > > > > > > reviews
> > > > > > > > > > > are
> > > > > > > > > > > > > ready,
> > > > > > > > > > > > > > > > > irrespectively of how long will it take. We
> > are
> > > > > about
> > > > > > > > > > quality,
> > > > > > > > > > > > not
> > > > > > > > > > > > > speed.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > > > > > dmagda@apache.org
> > > > > > > > > > >:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > What are the cases when the service can be
> > > > > > > redeployed?
> > > > > > > > > > > > Affinity,
> > > > > > > > > > > > > > > > failure,
> > > > > > > > > > > > > > > > > > etc., right. It would be good to list all
> > the
> > > > > cases
> > > > > > > on
> > > > > > > > the
> > > > > > > > > > > wiki
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > then
> > > > > > > > > > > > > > > > > > our tech writers will get everything
> > > documented.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> > > > > Daradur <
> > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Services reassignment process takes into
> > > > > account
> > > > > > > > previous
> > > > > > > > > > > > > assignments
> > > > > > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > > > > > So, in the described case, ServiceA won't
> > > be
> > > > > moved
> > > > > > > > from
> > > > > > > > > > > node1
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis
> > Magda
> > > <
> > > > > > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > First of all, thanks for archiving this
> > > > > milestone
> > > > > > > > and
> > > > > > > > > > > > > rolling out
> > > > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Speaking of the topology change events
> > > [1],
> > > > > does
> > > > > > > > the
> > > > > > > > > > new
> > > > > > > > > > > > > > > > architecture
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > > > > a running service redeployment when a
> > new
> > > > > node
> > > > > > > > joins?
> > > > > > > > > > For
> > > > > > > > > > > > > instance,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > > > > > say I have ServiceA running node1, then
> > > node2
> > > > > > > joins
> > > > > > > > > > and I
> > > > > > > > > > > > > don't
> > > > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > > service to be redeployed to any other
> > > node.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM
> > Vyacheslav
> > > > > > > Daradur <
> > > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Dmitriy, I published documentation in
> > > wiki:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM
> > Dmitriy
> > > > > Pavlov <
> > > > > > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> > > > > attached
> > > > > > > > docs.
> > > > > > > > > > > Could
> > > > > > > > > > > > > you
> > > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39
> > Vyacheslav
> > > > > > > Daradur <
> > > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I prepared a description of the
> > > > > implemented
> > > > > > > > > > > solution
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > attached
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > This should help during a review.
> > > > > Should I
> > > > > > > > post
> > > > > > > > > > the
> > > > > > > > > > > > > document
> > > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> > > > > review the
> > > > > > > > > > > solution
> > > > > > > > > > > > > [1] [2],
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> > > > > Vyacheslav
> > > > > > > > > > Daradur
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 -
> > > is in
> > > > > > > Patch
> > > > > > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > > > > > implementation.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > However, we need additional
> > > review
> > > > > from
> > > > > > > > other
> > > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1]
> > > and PR
> > > > > > > [2].
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Could someone step in and do
> > the
> > > > > review?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44
> > AM
> > > > > Denis
> > > > > > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net
> > to
> > > > > specify
> > > > > > > > > > service
> > > > > > > > > > > > > class name
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a
> > > problem.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> > > > > Vyacheslav
> > > > > > > > > > Daradur
> > > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I think that the
> > replacement
> > > of
> > > > > > > > serialized
> > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > makes
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > But how it should work for
> > > .NET
> > > > > > > client?
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> > 4:07
> > > PM
> > > > > > > Dmitriy
> > > > > > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> > > 6:10
> > > > > AM,
> > > > > > > > Nikita
> > > > > > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I am working on task
> > [1]
> > > that
> > > > > > > would
> > > > > > > > > > > replace
> > > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > > > > > by service's class name
> > > and
> > > > > > > > properties
> > > > > > > > > > > map
> > > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > The task describes that
> > > we
> > > > > should
> > > > > > > > use
> > > > > > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> > > > > {Map<String,
> > > > > > > > > > Object>
> > > > > > > > > > > > > > > > properties}
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> > > > > following
> > > > > > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. What about public
> > > methods?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them
> > as
> > > > > > > > deprecated
> > > > > > > > > > and
> > > > > > > > > > > > use
> > > > > > > > > > > > > class
> > > > > > > > > > > > > > > > name
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying
> > > methods
> > > > > > > with
> > > > > > > > new
> > > > > > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > srvcClsName,
> > > > > > > > Map<String,
> > > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > I think this makes sense,
> > > but I
> > > > > > > would
> > > > > > > > > > like
> > > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov
> > > should
> > > > > > > > comment
> > > > > > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String,
> > > Object>
> > > > > > > > properties}
> > > > > > > > > > > > > parameter
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> > > > > deploying
> > > > > > > > > > methods
> > > > > > > > > > > > > without
> > > > > > > > > > > > > > > > it?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> > srvcClsName,
> > > > > > > > Map<String,
> > > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > I would always ask the
> > > user to
> > > > > pass
> > > > > > > > the
> > > > > > > > > > > > > property
> > > > > > > > > > > > > > > > map, but
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Dmitriy Pavlov <dp...@apache.org>.
Hi Vyacheslav, Vladimir,

Could you please invite me, if you will set up a call.

ср, 21 нояб. 2018 г. в 13:08, Vladimir Ozerov <vo...@gridgain.com>:

> Hi Vyacheslav,
>
> Still not clear enough for me. I do not see a reason to send another over a
> ring in case of successful execution. The only reason is an error on a node
> which require correction (re-deploy to other node, full service undeploy,
> etc).
> I think it makes sense to organize another call to discuss current
> architecture. Otherwise we may spend too much time on emails.
>
> Vladimir.
>
> On Wed, Nov 21, 2018 at 12:57 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > The full map is needed:
> > 1) to propagate deployment results which could be different from
> > locally calculated in case of any errors;
> > 2) to transfer deployment errors across the cluster;
> > 3) to undeploy exceeded the number of service instances if needed;
> > 4) to get know other nodes that deployment process was finished, this
> > need to avoid calling services which have not been deployed yet (or
> > can't be deployed). We can't just store pending requests because of
> > time to deploy one service instances which may be significant.
> > On Wed, Nov 21, 2018 at 12:45 PM Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> > >
> > > Vyacheslav,
> > >
> > > I looked at the document and failed to find explanation why full maps
> are
> > > needed. Could you point me to a place where it is explained?
> > > I ask this because my impression from last discussion was that it is
> > never
> > > needed. Service status change is initiated by user action, then all
> nodes
> > > perform respective action locally, then they reply to coordinator, then
> > > coordinator reply to the client, no need a kind of "full" map over
> > > discovery again. The only situation when another message over ring is
> > > required, is when some node failed to execute local operation (for
> > whatever
> > > reason) and corrective action is required.
> > >
> > > Am I missing something?
> > >
> > > On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <
> daradurvs@gmail.com
> > >
> > > wrote:
> > >
> > > > Denis, I suggested new names above in the thread.
> > > >
> > > > Please, look at PME document [1] is should be quiet actual to show
> the
> > > > same flow.
> > > >
> > > > [1]
> > > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
> > > >
> > > > On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <
> > dmekhanikov@gmail.com>
> > > > wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > Actually, the service assignment is implemented in a way,
> > > > > that allows every node calculate the assignment itself, so no
> > information
> > > > > needs to be shared.
> > > > > The only data, that is sent between nodes is deployment results,
> > > > > and I don't see an analogy with exchange here.
> > > > >
> > > > > Denis
> > > > >
> > > > > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <
> vozerov@gridgain.com
> > >:
> > > > >
> > > > > > Hi Vyacheslav,
> > > > > >
> > > > > > Could you please explain in what situation coordinator needs to
> > collect
> > > > > > service deployments info from all nodes and share it with the
> > cluster?
> > > > I
> > > > > > cannot remember from our design discussion when it is needed.
> > Global
> > > > state
> > > > > > normally shared through discovery and only on node join, In this
> > case
> > > > we
> > > > > > use "DiscoveryDataBags", not separate messages.
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> > > > daradurvs@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I think request-response is not suitable terms.
> > > > > > >
> > > > > > > Nodes send to coordinator maps of actual service deployments
> > which
> > > > > > > contains what count of instances of each service node hosts
> > locally.
> > > > > > >
> > > > > > > Coordinator sends to the cluster the full map of deployments
> > across
> > > > the
> > > > > > > cluster.
> > > > > > >
> > > > > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> > > > vozerov@gridgain.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I do not know what is correct term :-) What I said is that
> > > > "exchange"
> > > > > > is
> > > > > > > > counter intuitive here. There is no "exchange", instead nodes
> > send
> > > > > > > > information to coordinator that they finished some operation.
> > E.g.
> > > > we
> > > > > > do
> > > > > > > > the same for schema changes (index creation), and as Denis
> > > > suggested,
> > > > > > > > Request-Response is correct suffixes here. Message name
> should
> > > > explain
> > > > > > > what
> > > > > > > > really happened, instead of describing things which are
> > somewhat
> > > > > > similar
> > > > > > > in
> > > > > > > > internal flow.
> > > > > > > >
> > > > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> > > > nizhikov@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello, Vladimir.
> > > > > > > > >
> > > > > > > > > What is correct term?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov
> > vozerov@gridgain.com
> > > > :
> > > > > > > > >
> > > > > > > > > > Agree. Service deployment has nothing to do with PME. We
> > > > should not
> > > > > > > use
> > > > > > > > > the
> > > > > > > > > > same term for different things.
> > > > > > > > > >
> > > > > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > > > > dmekhanikov@gmail.com>:
> > > > > > > > > >
> > > > > > > > > > > Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > I'm in process of reviewing your changes. Sorry for
> > taking so
> > > > > > long.
> > > > > > > > > > > I posted the first portion of review comments
> yesterday.
> > > > > > > > > > > I'd like to finish looking through the code. I'll post
> > more
> > > > > > > comments
> > > > > > > > > > later.
> > > > > > > > > > >
> > > > > > > > > > > I see, that you called things analogously to partition
> > map
> > > > > > > exchange.
> > > > > > > > > > > I realize, that there is an analogy in used procedures,
> > but I
> > > > > > don't
> > > > > > > > > > really
> > > > > > > > > > > like the idea to use the same names for everything.
> > > > > > > > > > > The partition map exchange is called this way because
> it
> > > > involves
> > > > > > > an
> > > > > > > > > > actual
> > > > > > > > > > > exchange of information.
> > > > > > > > > > > All nodes need to tell each other, which partitions
> they
> > > > have,
> > > > > > and
> > > > > > > what
> > > > > > > > > > > their states are.
> > > > > > > > > > >
> > > > > > > > > > > There is no exchange in case of service deployment, so
> I
> > > > would
> > > > > > > skip the
> > > > > > > > > > > "exchange" part.
> > > > > > > > > > > And *single message ->* *full message* look more like
> > > > *request ->
> > > > > > > > > > response*
> > > > > > > > > > > in case of services.
> > > > > > > > > > >
> > > > > > > > > > > Suppose we abandon the PME procedure and move to
> > something
> > > > else.
> > > > > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > > > > And I don't want to be in a situation, when I say to my
> > > > > > colleague a
> > > > > > > > > word
> > > > > > > > > > > "exchange",
> > > > > > > > > > > and get "which one?" in return.
> > > > > > > > > > > So, I'm for the meaningful names rather than analogous
> to
> > > > > > something
> > > > > > > > > else.
> > > > > > > > > > >
> > > > > > > > > > > What do you think?
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Denis, Yakov have you had a chance to review the
> > solution?
> > > > > > > > > > > >
> > > > > > > > > > > > Igniters, we need to define a list of reviewers,
> > otherwise
> > > > no
> > > > > > > end in
> > > > > > > > > > > sign.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm ready to continue work on the Service Grid,
> > including
> > > > new
> > > > > > > > > features
> > > > > > > > > > > > like hot-redeployment and versioning, also, I have
> > ideas
> > > > about
> > > > > > > new
> > > > > > > > > > > > tools for monitoring and management which will be
> > useful
> > > > for
> > > > > > our
> > > > > > > > > > > > end-users.
> > > > > > > > > > > >
> > > > > > > > > > > > But for continuing work we need to overcome this
> first
> > > > phase.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis, Yakov, feel free to contact me directly in
> > case of
> > > > > > > > > questions.
> > > > > > > > > > > > Thanks!
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Guys,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd like to take a look at the changes before
> they
> > are
> > > > > > > merged.
> > > > > > > > > > > > > > I'll do my best to finish the review before the
> > end of
> > > > the
> > > > > > > > > upcoming
> > > > > > > > > > > > week.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > > > > nizhikov@apache.org
> > > > > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Can we write the list of reviewers for this
> > feature?
> > > > > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > > > > Just a list of experts who should review this
> > > > feature.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> > > > пишет:
> > > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This is very huge thing with complex
> algorithms
> > > > behind.
> > > > > > > We
> > > > > > > > > > should
> > > > > > > > > > > > not
> > > > > > > > > > > > > > > merge
> > > > > > > > > > > > > > > > it to the product unless several additional
> > > > thorough
> > > > > > > reviews
> > > > > > > > > > are
> > > > > > > > > > > > ready,
> > > > > > > > > > > > > > > > irrespectively of how long will it take. We
> are
> > > > about
> > > > > > > > > quality,
> > > > > > > > > > > not
> > > > > > > > > > > > speed.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > > > > dmagda@apache.org
> > > > > > > > > >:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > What are the cases when the service can be
> > > > > > redeployed?
> > > > > > > > > > > Affinity,
> > > > > > > > > > > > > > > failure,
> > > > > > > > > > > > > > > > > etc., right. It would be good to list all
> the
> > > > cases
> > > > > > on
> > > > > > > the
> > > > > > > > > > wiki
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > then
> > > > > > > > > > > > > > > > > our tech writers will get everything
> > documented.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> > > > Daradur <
> > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Services reassignment process takes into
> > > > account
> > > > > > > previous
> > > > > > > > > > > > assignments
> > > > > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > > > > So, in the described case, ServiceA won't
> > be
> > > > moved
> > > > > > > from
> > > > > > > > > > node1
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis
> Magda
> > <
> > > > > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > First of all, thanks for archiving this
> > > > milestone
> > > > > > > and
> > > > > > > > > > > > rolling out
> > > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Speaking of the topology change events
> > [1],
> > > > does
> > > > > > > the
> > > > > > > > > new
> > > > > > > > > > > > > > > architecture
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > > > a running service redeployment when a
> new
> > > > node
> > > > > > > joins?
> > > > > > > > > For
> > > > > > > > > > > > instance,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > > > > say I have ServiceA running node1, then
> > node2
> > > > > > joins
> > > > > > > > > and I
> > > > > > > > > > > > don't
> > > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > > service to be redeployed to any other
> > node.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM
> Vyacheslav
> > > > > > Daradur <
> > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Dmitriy, I published documentation in
> > wiki:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM
> Dmitriy
> > > > Pavlov <
> > > > > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> > > > attached
> > > > > > > docs.
> > > > > > > > > > Could
> > > > > > > > > > > > you
> > > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39
> Vyacheslav
> > > > > > Daradur <
> > > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I prepared a description of the
> > > > implemented
> > > > > > > > > > solution
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > attached
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > This should help during a review.
> > > > Should I
> > > > > > > post
> > > > > > > > > the
> > > > > > > > > > > > document
> > > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> > > > review the
> > > > > > > > > > solution
> > > > > > > > > > > > [1] [2],
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> > > > Vyacheslav
> > > > > > > > > Daradur
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 -
> > is in
> > > > > > Patch
> > > > > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > > > > implementation.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > However, we need additional
> > review
> > > > from
> > > > > > > other
> > > > > > > > > > > Ignite
> > > > > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1]
> > and PR
> > > > > > [2].
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Could someone step in and do
> the
> > > > review?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44
> AM
> > > > Denis
> > > > > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net
> to
> > > > specify
> > > > > > > > > service
> > > > > > > > > > > > class name
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a
> > problem.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> > > > Vyacheslav
> > > > > > > > > Daradur
> > > > > > > > > > <
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I think that the
> replacement
> > of
> > > > > > > serialized
> > > > > > > > > > > > instance
> > > > > > > > > > > > > > > makes
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > But how it should work for
> > .NET
> > > > > > client?
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> 4:07
> > PM
> > > > > > Dmitriy
> > > > > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> > 6:10
> > > > AM,
> > > > > > > Nikita
> > > > > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > I am working on task
> [1]
> > that
> > > > > > would
> > > > > > > > > > replace
> > > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > > > > by service's class name
> > and
> > > > > > > properties
> > > > > > > > > > map
> > > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > The task describes that
> > we
> > > > should
> > > > > > > use
> > > > > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> > > > {Map<String,
> > > > > > > > > Object>
> > > > > > > > > > > > > > > properties}
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> > > > following
> > > > > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 1. What about public
> > methods?
> > > > > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them
> as
> > > > > > > deprecated
> > > > > > > > > and
> > > > > > > > > > > use
> > > > > > > > > > > > class
> > > > > > > > > > > > > > > name
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying
> > methods
> > > > > > with
> > > > > > > new
> > > > > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> srvcClsName,
> > > > > > > Map<String,
> > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I think this makes sense,
> > but I
> > > > > > would
> > > > > > > > > like
> > > > > > > > > > > > other
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov
> > should
> > > > > > > comment
> > > > > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String,
> > Object>
> > > > > > > properties}
> > > > > > > > > > > > parameter
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> > > > deploying
> > > > > > > > > methods
> > > > > > > > > > > > without
> > > > > > > > > > > > > > > it?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > > name, String
> srvcClsName,
> > > > > > > Map<String,
> > > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I would always ask the
> > user to
> > > > pass
> > > > > > > the
> > > > > > > > > > > > property
> > > > > > > > > > > > > > > map, but
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
Hi Vyacheslav,

Still not clear enough for me. I do not see a reason to send another over a
ring in case of successful execution. The only reason is an error on a node
which require correction (re-deploy to other node, full service undeploy,
etc).
I think it makes sense to organize another call to discuss current
architecture. Otherwise we may spend too much time on emails.

Vladimir.

On Wed, Nov 21, 2018 at 12:57 PM Vyacheslav Daradur <da...@gmail.com>
wrote:

> The full map is needed:
> 1) to propagate deployment results which could be different from
> locally calculated in case of any errors;
> 2) to transfer deployment errors across the cluster;
> 3) to undeploy exceeded the number of service instances if needed;
> 4) to get know other nodes that deployment process was finished, this
> need to avoid calling services which have not been deployed yet (or
> can't be deployed). We can't just store pending requests because of
> time to deploy one service instances which may be significant.
> On Wed, Nov 21, 2018 at 12:45 PM Vladimir Ozerov <vo...@gridgain.com>
> wrote:
> >
> > Vyacheslav,
> >
> > I looked at the document and failed to find explanation why full maps are
> > needed. Could you point me to a place where it is explained?
> > I ask this because my impression from last discussion was that it is
> never
> > needed. Service status change is initiated by user action, then all nodes
> > perform respective action locally, then they reply to coordinator, then
> > coordinator reply to the client, no need a kind of "full" map over
> > discovery again. The only situation when another message over ring is
> > required, is when some node failed to execute local operation (for
> whatever
> > reason) and corrective action is required.
> >
> > Am I missing something?
> >
> > On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <daradurvs@gmail.com
> >
> > wrote:
> >
> > > Denis, I suggested new names above in the thread.
> > >
> > > Please, look at PME document [1] is should be quiet actual to show the
> > > same flow.
> > >
> > > [1]
> > >
> https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
> > >
> > > On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > wrote:
> > > >
> > > > Vyacheslav,
> > > >
> > > > Actually, the service assignment is implemented in a way,
> > > > that allows every node calculate the assignment itself, so no
> information
> > > > needs to be shared.
> > > > The only data, that is sent between nodes is deployment results,
> > > > and I don't see an analogy with exchange here.
> > > >
> > > > Denis
> > > >
> > > > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <vozerov@gridgain.com
> >:
> > > >
> > > > > Hi Vyacheslav,
> > > > >
> > > > > Could you please explain in what situation coordinator needs to
> collect
> > > > > service deployments info from all nodes and share it with the
> cluster?
> > > I
> > > > > cannot remember from our design discussion when it is needed.
> Global
> > > state
> > > > > normally shared through discovery and only on node join, In this
> case
> > > we
> > > > > use "DiscoveryDataBags", not separate messages.
> > > > >
> > > > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> > > daradurvs@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I think request-response is not suitable terms.
> > > > > >
> > > > > > Nodes send to coordinator maps of actual service deployments
> which
> > > > > > contains what count of instances of each service node hosts
> locally.
> > > > > >
> > > > > > Coordinator sends to the cluster the full map of deployments
> across
> > > the
> > > > > > cluster.
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> > > vozerov@gridgain.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > I do not know what is correct term :-) What I said is that
> > > "exchange"
> > > > > is
> > > > > > > counter intuitive here. There is no "exchange", instead nodes
> send
> > > > > > > information to coordinator that they finished some operation.
> E.g.
> > > we
> > > > > do
> > > > > > > the same for schema changes (index creation), and as Denis
> > > suggested,
> > > > > > > Request-Response is correct suffixes here. Message name should
> > > explain
> > > > > > what
> > > > > > > really happened, instead of describing things which are
> somewhat
> > > > > similar
> > > > > > in
> > > > > > > internal flow.
> > > > > > >
> > > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> > > nizhikov@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello, Vladimir.
> > > > > > > >
> > > > > > > > What is correct term?
> > > > > > > >
> > > > > > > >
> > > > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov
> vozerov@gridgain.com
> > > :
> > > > > > > >
> > > > > > > > > Agree. Service deployment has nothing to do with PME. We
> > > should not
> > > > > > use
> > > > > > > > the
> > > > > > > > > same term for different things.
> > > > > > > > >
> > > > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > > > dmekhanikov@gmail.com>:
> > > > > > > > >
> > > > > > > > > > Vyacheslav,
> > > > > > > > > >
> > > > > > > > > > I'm in process of reviewing your changes. Sorry for
> taking so
> > > > > long.
> > > > > > > > > > I posted the first portion of review comments yesterday.
> > > > > > > > > > I'd like to finish looking through the code. I'll post
> more
> > > > > > comments
> > > > > > > > > later.
> > > > > > > > > >
> > > > > > > > > > I see, that you called things analogously to partition
> map
> > > > > > exchange.
> > > > > > > > > > I realize, that there is an analogy in used procedures,
> but I
> > > > > don't
> > > > > > > > > really
> > > > > > > > > > like the idea to use the same names for everything.
> > > > > > > > > > The partition map exchange is called this way because it
> > > involves
> > > > > > an
> > > > > > > > > actual
> > > > > > > > > > exchange of information.
> > > > > > > > > > All nodes need to tell each other, which partitions they
> > > have,
> > > > > and
> > > > > > what
> > > > > > > > > > their states are.
> > > > > > > > > >
> > > > > > > > > > There is no exchange in case of service deployment, so I
> > > would
> > > > > > skip the
> > > > > > > > > > "exchange" part.
> > > > > > > > > > And *single message ->* *full message* look more like
> > > *request ->
> > > > > > > > > response*
> > > > > > > > > > in case of services.
> > > > > > > > > >
> > > > > > > > > > Suppose we abandon the PME procedure and move to
> something
> > > else.
> > > > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > > > And I don't want to be in a situation, when I say to my
> > > > > colleague a
> > > > > > > > word
> > > > > > > > > > "exchange",
> > > > > > > > > > and get "which one?" in return.
> > > > > > > > > > So, I'm for the meaningful names rather than analogous to
> > > > > something
> > > > > > > > else.
> > > > > > > > > >
> > > > > > > > > > What do you think?
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com
> > > > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Denis, Yakov have you had a chance to review the
> solution?
> > > > > > > > > > >
> > > > > > > > > > > Igniters, we need to define a list of reviewers,
> otherwise
> > > no
> > > > > > end in
> > > > > > > > > > sign.
> > > > > > > > > > >
> > > > > > > > > > > I'm ready to continue work on the Service Grid,
> including
> > > new
> > > > > > > > features
> > > > > > > > > > > like hot-redeployment and versioning, also, I have
> ideas
> > > about
> > > > > > new
> > > > > > > > > > > tools for monitoring and management which will be
> useful
> > > for
> > > > > our
> > > > > > > > > > > end-users.
> > > > > > > > > > >
> > > > > > > > > > > But for continuing work we need to overcome this first
> > > phase.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Denis, Yakov, feel free to contact me directly in
> case of
> > > > > > > > questions.
> > > > > > > > > > > Thanks!
> > > > > > > > > > > >
> > > > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Guys,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'd like to take a look at the changes before they
> are
> > > > > > merged.
> > > > > > > > > > > > > I'll do my best to finish the review before the
> end of
> > > the
> > > > > > > > upcoming
> > > > > > > > > > > week.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thanks!
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > > > nizhikov@apache.org
> > > > > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Can we write the list of reviewers for this
> feature?
> > > > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > > > Just a list of experts who should review this
> > > feature.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> > > пишет:
> > > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This is very huge thing with complex algorithms
> > > behind.
> > > > > > We
> > > > > > > > > should
> > > > > > > > > > > not
> > > > > > > > > > > > > > merge
> > > > > > > > > > > > > > > it to the product unless several additional
> > > thorough
> > > > > > reviews
> > > > > > > > > are
> > > > > > > > > > > ready,
> > > > > > > > > > > > > > > irrespectively of how long will it take. We are
> > > about
> > > > > > > > quality,
> > > > > > > > > > not
> > > > > > > > > > > speed.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > > > dmagda@apache.org
> > > > > > > > >:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > What are the cases when the service can be
> > > > > redeployed?
> > > > > > > > > > Affinity,
> > > > > > > > > > > > > > failure,
> > > > > > > > > > > > > > > > etc., right. It would be good to list all the
> > > cases
> > > > > on
> > > > > > the
> > > > > > > > > wiki
> > > > > > > > > > > and
> > > > > > > > > > > > > > then
> > > > > > > > > > > > > > > > our tech writers will get everything
> documented.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> > > Daradur <
> > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Services reassignment process takes into
> > > account
> > > > > > previous
> > > > > > > > > > > assignments
> > > > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > > > So, in the described case, ServiceA won't
> be
> > > moved
> > > > > > from
> > > > > > > > > node1
> > > > > > > > > > > to
> > > > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda
> <
> > > > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > First of all, thanks for archiving this
> > > milestone
> > > > > > and
> > > > > > > > > > > rolling out
> > > > > > > > > > > > > > these
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Speaking of the topology change events
> [1],
> > > does
> > > > > > the
> > > > > > > > new
> > > > > > > > > > > > > > architecture
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > > a running service redeployment when a new
> > > node
> > > > > > joins?
> > > > > > > > For
> > > > > > > > > > > instance,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > > > say I have ServiceA running node1, then
> node2
> > > > > joins
> > > > > > > > and I
> > > > > > > > > > > don't
> > > > > > > > > > > > > > want
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > > service to be redeployed to any other
> node.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav
> > > > > Daradur <
> > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Dmitriy, I published documentation in
> wiki:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy
> > > Pavlov <
> > > > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> > > attached
> > > > > > docs.
> > > > > > > > > Could
> > > > > > > > > > > you
> > > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav
> > > > > Daradur <
> > > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I prepared a description of the
> > > implemented
> > > > > > > > > solution
> > > > > > > > > > > and
> > > > > > > > > > > > > > attached
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > This should help during a review.
> > > Should I
> > > > > > post
> > > > > > > > the
> > > > > > > > > > > document
> > > > > > > > > > > > > > into
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> > > review the
> > > > > > > > > solution
> > > > > > > > > > > [1] [2],
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> > > Vyacheslav
> > > > > > > > Daradur
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 -
> is in
> > > > > Patch
> > > > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > > > implementation.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > However, we need additional
> review
> > > from
> > > > > > other
> > > > > > > > > > Ignite
> > > > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1]
> and PR
> > > > > [2].
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Could someone step in and do the
> > > review?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > > [2]
> > > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM
> > > Denis
> > > > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net to
> > > specify
> > > > > > > > service
> > > > > > > > > > > class name
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a
> problem.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> > > Vyacheslav
> > > > > > > > Daradur
> > > > > > > > > <
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think that the replacement
> of
> > > > > > serialized
> > > > > > > > > > > instance
> > > > > > > > > > > > > > makes
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > But how it should work for
> .NET
> > > > > client?
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07
> PM
> > > > > Dmitriy
> > > > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at
> 6:10
> > > AM,
> > > > > > Nikita
> > > > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I am working on task [1]
> that
> > > > > would
> > > > > > > > > replace
> > > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > > > by service's class name
> and
> > > > > > properties
> > > > > > > > > map
> > > > > > > > > > in
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > The task describes that
> we
> > > should
> > > > > > use
> > > > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> > > {Map<String,
> > > > > > > > Object>
> > > > > > > > > > > > > > properties}
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> > > following
> > > > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 1. What about public
> methods?
> > > > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > > > > > deprecated
> > > > > > > > and
> > > > > > > > > > use
> > > > > > > > > > > class
> > > > > > > > > > > > > > name
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying
> methods
> > > > > with
> > > > > > new
> > > > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > > > Map<String,
> > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I think this makes sense,
> but I
> > > > > would
> > > > > > > > like
> > > > > > > > > > > other
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov
> should
> > > > > > comment
> > > > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String,
> Object>
> > > > > > properties}
> > > > > > > > > > > parameter
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> > > deploying
> > > > > > > > methods
> > > > > > > > > > > without
> > > > > > > > > > > > > > it?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > > public
> > > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > > > Map<String,
> > > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I would always ask the
> user to
> > > pass
> > > > > > the
> > > > > > > > > > > property
> > > > > > > > > > > > > > map, but
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
The full map is needed:
1) to propagate deployment results which could be different from
locally calculated in case of any errors;
2) to transfer deployment errors across the cluster;
3) to undeploy exceeded the number of service instances if needed;
4) to get know other nodes that deployment process was finished, this
need to avoid calling services which have not been deployed yet (or
can't be deployed). We can't just store pending requests because of
time to deploy one service instances which may be significant.
On Wed, Nov 21, 2018 at 12:45 PM Vladimir Ozerov <vo...@gridgain.com> wrote:
>
> Vyacheslav,
>
> I looked at the document and failed to find explanation why full maps are
> needed. Could you point me to a place where it is explained?
> I ask this because my impression from last discussion was that it is never
> needed. Service status change is initiated by user action, then all nodes
> perform respective action locally, then they reply to coordinator, then
> coordinator reply to the client, no need a kind of "full" map over
> discovery again. The only situation when another message over ring is
> required, is when some node failed to execute local operation (for whatever
> reason) and corrective action is required.
>
> Am I missing something?
>
> On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > Denis, I suggested new names above in the thread.
> >
> > Please, look at PME document [1] is should be quiet actual to show the
> > same flow.
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
> >
> > On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <dm...@gmail.com>
> > wrote:
> > >
> > > Vyacheslav,
> > >
> > > Actually, the service assignment is implemented in a way,
> > > that allows every node calculate the assignment itself, so no information
> > > needs to be shared.
> > > The only data, that is sent between nodes is deployment results,
> > > and I don't see an analogy with exchange here.
> > >
> > > Denis
> > >
> > > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <vo...@gridgain.com>:
> > >
> > > > Hi Vyacheslav,
> > > >
> > > > Could you please explain in what situation coordinator needs to collect
> > > > service deployments info from all nodes and share it with the cluster?
> > I
> > > > cannot remember from our design discussion when it is needed. Global
> > state
> > > > normally shared through discovery and only on node join, In this case
> > we
> > > > use "DiscoveryDataBags", not separate messages.
> > > >
> > > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > >
> > > > > I think request-response is not suitable terms.
> > > > >
> > > > > Nodes send to coordinator maps of actual service deployments which
> > > > > contains what count of instances of each service node hosts locally.
> > > > >
> > > > > Coordinator sends to the cluster the full map of deployments across
> > the
> > > > > cluster.
> > > > >
> > > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> > vozerov@gridgain.com>
> > > > > wrote:
> > > > > >
> > > > > > I do not know what is correct term :-) What I said is that
> > "exchange"
> > > > is
> > > > > > counter intuitive here. There is no "exchange", instead nodes send
> > > > > > information to coordinator that they finished some operation. E.g.
> > we
> > > > do
> > > > > > the same for schema changes (index creation), and as Denis
> > suggested,
> > > > > > Request-Response is correct suffixes here. Message name should
> > explain
> > > > > what
> > > > > > really happened, instead of describing things which are somewhat
> > > > similar
> > > > > in
> > > > > > internal flow.
> > > > > >
> > > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> > nizhikov@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello, Vladimir.
> > > > > > >
> > > > > > > What is correct term?
> > > > > > >
> > > > > > >
> > > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com
> > :
> > > > > > >
> > > > > > > > Agree. Service deployment has nothing to do with PME. We
> > should not
> > > > > use
> > > > > > > the
> > > > > > > > same term for different things.
> > > > > > > >
> > > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > > dmekhanikov@gmail.com>:
> > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > I'm in process of reviewing your changes. Sorry for taking so
> > > > long.
> > > > > > > > > I posted the first portion of review comments yesterday.
> > > > > > > > > I'd like to finish looking through the code. I'll post more
> > > > > comments
> > > > > > > > later.
> > > > > > > > >
> > > > > > > > > I see, that you called things analogously to partition map
> > > > > exchange.
> > > > > > > > > I realize, that there is an analogy in used procedures, but I
> > > > don't
> > > > > > > > really
> > > > > > > > > like the idea to use the same names for everything.
> > > > > > > > > The partition map exchange is called this way because it
> > involves
> > > > > an
> > > > > > > > actual
> > > > > > > > > exchange of information.
> > > > > > > > > All nodes need to tell each other, which partitions they
> > have,
> > > > and
> > > > > what
> > > > > > > > > their states are.
> > > > > > > > >
> > > > > > > > > There is no exchange in case of service deployment, so I
> > would
> > > > > skip the
> > > > > > > > > "exchange" part.
> > > > > > > > > And *single message ->* *full message* look more like
> > *request ->
> > > > > > > > response*
> > > > > > > > > in case of services.
> > > > > > > > >
> > > > > > > > > Suppose we abandon the PME procedure and move to something
> > else.
> > > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > > And I don't want to be in a situation, when I say to my
> > > > colleague a
> > > > > > > word
> > > > > > > > > "exchange",
> > > > > > > > > and get "which one?" in return.
> > > > > > > > > So, I'm for the meaningful names rather than analogous to
> > > > something
> > > > > > > else.
> > > > > > > > >
> > > > > > > > > What do you think?
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > > daradurvs@gmail.com
> > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > > > > > >
> > > > > > > > > > Igniters, we need to define a list of reviewers, otherwise
> > no
> > > > > end in
> > > > > > > > > sign.
> > > > > > > > > >
> > > > > > > > > > I'm ready to continue work on the Service Grid, including
> > new
> > > > > > > features
> > > > > > > > > > like hot-redeployment and versioning, also, I have ideas
> > about
> > > > > new
> > > > > > > > > > tools for monitoring and management which will be useful
> > for
> > > > our
> > > > > > > > > > end-users.
> > > > > > > > > >
> > > > > > > > > > But for continuing work we need to overcome this first
> > phase.
> > > > > > > > > >
> > > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > > > > > questions.
> > > > > > > > > > Thanks!
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Guys,
> > > > > > > > > > > >
> > > > > > > > > > > > I'd like to take a look at the changes before they are
> > > > > merged.
> > > > > > > > > > > > I'll do my best to finish the review before the end of
> > the
> > > > > > > upcoming
> > > > > > > > > > week.
> > > > > > > > > > > >
> > > > > > > > > > > > Thanks!
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > > nizhikov@apache.org
> > > > > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > > Just a list of experts who should review this
> > feature.
> > > > > > > > > > > > >
> > > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> > пишет:
> > > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This is very huge thing with complex algorithms
> > behind.
> > > > > We
> > > > > > > > should
> > > > > > > > > > not
> > > > > > > > > > > > > merge
> > > > > > > > > > > > > > it to the product unless several additional
> > thorough
> > > > > reviews
> > > > > > > > are
> > > > > > > > > > ready,
> > > > > > > > > > > > > > irrespectively of how long will it take. We are
> > about
> > > > > > > quality,
> > > > > > > > > not
> > > > > > > > > > speed.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > > dmagda@apache.org
> > > > > > > >:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > What are the cases when the service can be
> > > > redeployed?
> > > > > > > > > Affinity,
> > > > > > > > > > > > > failure,
> > > > > > > > > > > > > > > etc., right. It would be good to list all the
> > cases
> > > > on
> > > > > the
> > > > > > > > wiki
> > > > > > > > > > and
> > > > > > > > > > > > > then
> > > > > > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> > Daradur <
> > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Services reassignment process takes into
> > account
> > > > > previous
> > > > > > > > > > assignments
> > > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > > So, in the described case, ServiceA won't be
> > moved
> > > > > from
> > > > > > > > node1
> > > > > > > > > > to
> > > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > First of all, thanks for archiving this
> > milestone
> > > > > and
> > > > > > > > > > rolling out
> > > > > > > > > > > > > these
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Speaking of the topology change events [1],
> > does
> > > > > the
> > > > > > > new
> > > > > > > > > > > > > architecture
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > > a running service redeployment when a new
> > node
> > > > > joins?
> > > > > > > For
> > > > > > > > > > instance,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > > say I have ServiceA running node1, then node2
> > > > joins
> > > > > > > and I
> > > > > > > > > > don't
> > > > > > > > > > > > > want
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav
> > > > Daradur <
> > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy
> > Pavlov <
> > > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> > attached
> > > > > docs.
> > > > > > > > Could
> > > > > > > > > > you
> > > > > > > > > > > > > please
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav
> > > > Daradur <
> > > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I prepared a description of the
> > implemented
> > > > > > > > solution
> > > > > > > > > > and
> > > > > > > > > > > > > attached
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > This should help during a review.
> > Should I
> > > > > post
> > > > > > > the
> > > > > > > > > > document
> > > > > > > > > > > > > into
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> > review the
> > > > > > > > solution
> > > > > > > > > > [1] [2],
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > [2]
> > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> > Vyacheslav
> > > > > > > Daradur
> > > > > > > > <
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in
> > > > Patch
> > > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > > implementation.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > However, we need additional review
> > from
> > > > > other
> > > > > > > > > Ignite
> > > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR
> > > > [2].
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Could someone step in and do the
> > review?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > > [2]
> > > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM
> > Denis
> > > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net to
> > specify
> > > > > > > service
> > > > > > > > > > class name
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> > Vyacheslav
> > > > > > > Daradur
> > > > > > > > <
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think that the replacement of
> > > > > serialized
> > > > > > > > > > instance
> > > > > > > > > > > > > makes
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > But how it should work for .NET
> > > > client?
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM
> > > > Dmitriy
> > > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10
> > AM,
> > > > > Nikita
> > > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I am working on task [1] that
> > > > would
> > > > > > > > replace
> > > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > > by service's class name and
> > > > > properties
> > > > > > > > map
> > > > > > > > > in
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > The task describes that we
> > should
> > > > > use
> > > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> > {Map<String,
> > > > > > > Object>
> > > > > > > > > > > > > properties}
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> > following
> > > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > > > > deprecated
> > > > > > > and
> > > > > > > > > use
> > > > > > > > > > class
> > > > > > > > > > > > > name
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying methods
> > > > with
> > > > > new
> > > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > > public
> > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > public
> > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > > Map<String,
> > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I think this makes sense, but I
> > > > would
> > > > > > > like
> > > > > > > > > > other
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> > > > > comment
> > > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> > > > > properties}
> > > > > > > > > > parameter
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> > deploying
> > > > > > > methods
> > > > > > > > > > without
> > > > > > > > > > > > > it?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > public
> > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > > public
> > IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > > Map<String,
> > > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I would always ask the user to
> > pass
> > > > > the
> > > > > > > > > > property
> > > > > > > > > > > > > map, but
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



--
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
Vyacheslav,

I looked at the document and failed to find explanation why full maps are
needed. Could you point me to a place where it is explained?
I ask this because my impression from last discussion was that it is never
needed. Service status change is initiated by user action, then all nodes
perform respective action locally, then they reply to coordinator, then
coordinator reply to the client, no need a kind of "full" map over
discovery again. The only situation when another message over ring is
required, is when some node failed to execute local operation (for whatever
reason) and corrective action is required.

Am I missing something?

On Wed, Nov 21, 2018 at 11:50 AM Vyacheslav Daradur <da...@gmail.com>
wrote:

> Denis, I suggested new names above in the thread.
>
> Please, look at PME document [1] is should be quiet actual to show the
> same flow.
>
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood
>
> On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <dm...@gmail.com>
> wrote:
> >
> > Vyacheslav,
> >
> > Actually, the service assignment is implemented in a way,
> > that allows every node calculate the assignment itself, so no information
> > needs to be shared.
> > The only data, that is sent between nodes is deployment results,
> > and I don't see an analogy with exchange here.
> >
> > Denis
> >
> > ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <vo...@gridgain.com>:
> >
> > > Hi Vyacheslav,
> > >
> > > Could you please explain in what situation coordinator needs to collect
> > > service deployments info from all nodes and share it with the cluster?
> I
> > > cannot remember from our design discussion when it is needed. Global
> state
> > > normally shared through discovery and only on node join, In this case
> we
> > > use "DiscoveryDataBags", not separate messages.
> > >
> > > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > >
> > > > I think request-response is not suitable terms.
> > > >
> > > > Nodes send to coordinator maps of actual service deployments which
> > > > contains what count of instances of each service node hosts locally.
> > > >
> > > > Coordinator sends to the cluster the full map of deployments across
> the
> > > > cluster.
> > > >
> > > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <
> vozerov@gridgain.com>
> > > > wrote:
> > > > >
> > > > > I do not know what is correct term :-) What I said is that
> "exchange"
> > > is
> > > > > counter intuitive here. There is no "exchange", instead nodes send
> > > > > information to coordinator that they finished some operation. E.g.
> we
> > > do
> > > > > the same for schema changes (index creation), and as Denis
> suggested,
> > > > > Request-Response is correct suffixes here. Message name should
> explain
> > > > what
> > > > > really happened, instead of describing things which are somewhat
> > > similar
> > > > in
> > > > > internal flow.
> > > > >
> > > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <
> nizhikov@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Hello, Vladimir.
> > > > > >
> > > > > > What is correct term?
> > > > > >
> > > > > >
> > > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com
> :
> > > > > >
> > > > > > > Agree. Service deployment has nothing to do with PME. We
> should not
> > > > use
> > > > > > the
> > > > > > > same term for different things.
> > > > > > >
> > > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > > dmekhanikov@gmail.com>:
> > > > > > >
> > > > > > > > Vyacheslav,
> > > > > > > >
> > > > > > > > I'm in process of reviewing your changes. Sorry for taking so
> > > long.
> > > > > > > > I posted the first portion of review comments yesterday.
> > > > > > > > I'd like to finish looking through the code. I'll post more
> > > > comments
> > > > > > > later.
> > > > > > > >
> > > > > > > > I see, that you called things analogously to partition map
> > > > exchange.
> > > > > > > > I realize, that there is an analogy in used procedures, but I
> > > don't
> > > > > > > really
> > > > > > > > like the idea to use the same names for everything.
> > > > > > > > The partition map exchange is called this way because it
> involves
> > > > an
> > > > > > > actual
> > > > > > > > exchange of information.
> > > > > > > > All nodes need to tell each other, which partitions they
> have,
> > > and
> > > > what
> > > > > > > > their states are.
> > > > > > > >
> > > > > > > > There is no exchange in case of service deployment, so I
> would
> > > > skip the
> > > > > > > > "exchange" part.
> > > > > > > > And *single message ->* *full message* look more like
> *request ->
> > > > > > > response*
> > > > > > > > in case of services.
> > > > > > > >
> > > > > > > > Suppose we abandon the PME procedure and move to something
> else.
> > > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > > And I don't want to be in a situation, when I say to my
> > > colleague a
> > > > > > word
> > > > > > > > "exchange",
> > > > > > > > and get "which one?" in return.
> > > > > > > > So, I'm for the meaningful names rather than analogous to
> > > something
> > > > > > else.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > > daradurvs@gmail.com
> > > > > > >:
> > > > > > > >
> > > > > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > > > > >
> > > > > > > > > Igniters, we need to define a list of reviewers, otherwise
> no
> > > > end in
> > > > > > > > sign.
> > > > > > > > >
> > > > > > > > > I'm ready to continue work on the Service Grid, including
> new
> > > > > > features
> > > > > > > > > like hot-redeployment and versioning, also, I have ideas
> about
> > > > new
> > > > > > > > > tools for monitoring and management which will be useful
> for
> > > our
> > > > > > > > > end-users.
> > > > > > > > >
> > > > > > > > > But for continuing work we need to overcome this first
> phase.
> > > > > > > > >
> > > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > > > > questions.
> > > > > > > > > Thanks!
> > > > > > > > > >
> > > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Guys,
> > > > > > > > > > >
> > > > > > > > > > > I'd like to take a look at the changes before they are
> > > > merged.
> > > > > > > > > > > I'll do my best to finish the review before the end of
> the
> > > > > > upcoming
> > > > > > > > > week.
> > > > > > > > > > >
> > > > > > > > > > > Thanks!
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > > nizhikov@apache.org
> > > > > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > > >
> > > > > > > > > > > > I'm agree with you.
> > > > > > > > > > > >
> > > > > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > > Just a list of experts who should review this
> feature.
> > > > > > > > > > > >
> > > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov
> пишет:
> > > > > > > > > > > > > Igniters,
> > > > > > > > > > > > >
> > > > > > > > > > > > > This is very huge thing with complex algorithms
> behind.
> > > > We
> > > > > > > should
> > > > > > > > > not
> > > > > > > > > > > > merge
> > > > > > > > > > > > > it to the product unless several additional
> thorough
> > > > reviews
> > > > > > > are
> > > > > > > > > ready,
> > > > > > > > > > > > > irrespectively of how long will it take. We are
> about
> > > > > > quality,
> > > > > > > > not
> > > > > > > > > speed.
> > > > > > > > > > > > >
> > > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > > dmagda@apache.org
> > > > > > >:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > What are the cases when the service can be
> > > redeployed?
> > > > > > > > Affinity,
> > > > > > > > > > > > failure,
> > > > > > > > > > > > > > etc., right. It would be good to list all the
> cases
> > > on
> > > > the
> > > > > > > wiki
> > > > > > > > > and
> > > > > > > > > > > > then
> > > > > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav
> Daradur <
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Services reassignment process takes into
> account
> > > > previous
> > > > > > > > > assignments
> > > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > > So, in the described case, ServiceA won't be
> moved
> > > > from
> > > > > > > node1
> > > > > > > > > to
> > > > > > > > > > > > node2.
> > > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > > > > dmagda@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > First of all, thanks for archiving this
> milestone
> > > > and
> > > > > > > > > rolling out
> > > > > > > > > > > > these
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Speaking of the topology change events [1],
> does
> > > > the
> > > > > > new
> > > > > > > > > > > > architecture
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > > a running service redeployment when a new
> node
> > > > joins?
> > > > > > For
> > > > > > > > > instance,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > > say I have ServiceA running node1, then node2
> > > joins
> > > > > > and I
> > > > > > > > > don't
> > > > > > > > > > > > want
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav
> > > Daradur <
> > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy
> Pavlov <
> > > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi I think wiki is better than any
> attached
> > > > docs.
> > > > > > > Could
> > > > > > > > > you
> > > > > > > > > > > > please
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav
> > > Daradur <
> > > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I prepared a description of the
> implemented
> > > > > > > solution
> > > > > > > > > and
> > > > > > > > > > > > attached
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > This should help during a review.
> Should I
> > > > post
> > > > > > the
> > > > > > > > > document
> > > > > > > > > > > > into
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts
> review the
> > > > > > > solution
> > > > > > > > > [1] [2],
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > [2]
> > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM
> Vyacheslav
> > > > > > Daradur
> > > > > > > <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in
> > > Patch
> > > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > > implementation.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > However, we need additional review
> from
> > > > other
> > > > > > > > Ignite
> > > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR
> > > [2].
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Could someone step in and do the
> review?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > > [2]
> > > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM
> Denis
> > > > > > > Mekhanikov <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Does it make sense for .Net to
> specify
> > > > > > service
> > > > > > > > > class name
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33
> Vyacheslav
> > > > > > Daradur
> > > > > > > <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think that the replacement of
> > > > serialized
> > > > > > > > > instance
> > > > > > > > > > > > makes
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > But how it should work for .NET
> > > client?
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM
> > > Dmitriy
> > > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10
> AM,
> > > > Nikita
> > > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I am working on task [1] that
> > > would
> > > > > > > replace
> > > > > > > > > > > > serialized
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > > by service's class name and
> > > > properties
> > > > > > > map
> > > > > > > > in
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > The task describes that we
> should
> > > > use
> > > > > > > > > > > > > > > > > > > > > > > > {String className} +
> {Map<String,
> > > > > > Object>
> > > > > > > > > > > > properties}
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the
> following
> > > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > > > deprecated
> > > > > > and
> > > > > > > > use
> > > > > > > > > class
> > > > > > > > > > > > name
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > > Also to add deploying methods
> > > with
> > > > new
> > > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > > public
> IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > public
> IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > Map<String,
> > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I think this makes sense, but I
> > > would
> > > > > > like
> > > > > > > > > other
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> > > > comment
> > > > > > > here.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> > > > properties}
> > > > > > > > > parameter
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add
> deploying
> > > > > > methods
> > > > > > > > > without
> > > > > > > > > > > > it?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > public
> IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > > public
> IgniteInternalFuture<?>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > > Map<String,
> > > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I would always ask the user to
> pass
> > > > the
> > > > > > > > > property
> > > > > > > > > > > > map, but
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis, I suggested new names above in the thread.

Please, look at PME document [1] is should be quiet actual to show the
same flow.

[1] https://cwiki.apache.org/confluence/display/IGNITE/%28Partition+Map%29+Exchange+-+under+the+hood

On Wed, Nov 21, 2018 at 11:43 AM Denis Mekhanikov <dm...@gmail.com> wrote:
>
> Vyacheslav,
>
> Actually, the service assignment is implemented in a way,
> that allows every node calculate the assignment itself, so no information
> needs to be shared.
> The only data, that is sent between nodes is deployment results,
> and I don't see an analogy with exchange here.
>
> Denis
>
> ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <vo...@gridgain.com>:
>
> > Hi Vyacheslav,
> >
> > Could you please explain in what situation coordinator needs to collect
> > service deployments info from all nodes and share it with the cluster? I
> > cannot remember from our design discussion when it is needed. Global state
> > normally shared through discovery and only on node join, In this case we
> > use "DiscoveryDataBags", not separate messages.
> >
> > On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> >
> > > I think request-response is not suitable terms.
> > >
> > > Nodes send to coordinator maps of actual service deployments which
> > > contains what count of instances of each service node hosts locally.
> > >
> > > Coordinator sends to the cluster the full map of deployments across the
> > > cluster.
> > >
> > > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <vo...@gridgain.com>
> > > wrote:
> > > >
> > > > I do not know what is correct term :-) What I said is that "exchange"
> > is
> > > > counter intuitive here. There is no "exchange", instead nodes send
> > > > information to coordinator that they finished some operation. E.g. we
> > do
> > > > the same for schema changes (index creation), and as Denis suggested,
> > > > Request-Response is correct suffixes here. Message name should explain
> > > what
> > > > really happened, instead of describing things which are somewhat
> > similar
> > > in
> > > > internal flow.
> > > >
> > > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
> > > > wrote:
> > > >
> > > > > Hello, Vladimir.
> > > > >
> > > > > What is correct term?
> > > > >
> > > > >
> > > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
> > > > >
> > > > > > Agree. Service deployment has nothing to do with PME. We should not
> > > use
> > > > > the
> > > > > > same term for different things.
> > > > > >
> > > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > > dmekhanikov@gmail.com>:
> > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > I'm in process of reviewing your changes. Sorry for taking so
> > long.
> > > > > > > I posted the first portion of review comments yesterday.
> > > > > > > I'd like to finish looking through the code. I'll post more
> > > comments
> > > > > > later.
> > > > > > >
> > > > > > > I see, that you called things analogously to partition map
> > > exchange.
> > > > > > > I realize, that there is an analogy in used procedures, but I
> > don't
> > > > > > really
> > > > > > > like the idea to use the same names for everything.
> > > > > > > The partition map exchange is called this way because it involves
> > > an
> > > > > > actual
> > > > > > > exchange of information.
> > > > > > > All nodes need to tell each other, which partitions they have,
> > and
> > > what
> > > > > > > their states are.
> > > > > > >
> > > > > > > There is no exchange in case of service deployment, so I would
> > > skip the
> > > > > > > "exchange" part.
> > > > > > > And *single message ->* *full message* look more like *request ->
> > > > > > response*
> > > > > > > in case of services.
> > > > > > >
> > > > > > > Suppose we abandon the PME procedure and move to something else.
> > > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > > And I don't want to be in a situation, when I say to my
> > colleague a
> > > > > word
> > > > > > > "exchange",
> > > > > > > and get "which one?" in return.
> > > > > > > So, I'm for the meaningful names rather than analogous to
> > something
> > > > > else.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > > daradurvs@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > > > >
> > > > > > > > Igniters, we need to define a list of reviewers, otherwise no
> > > end in
> > > > > > > sign.
> > > > > > > >
> > > > > > > > I'm ready to continue work on the Service Grid, including new
> > > > > features
> > > > > > > > like hot-redeployment and versioning, also, I have ideas about
> > > new
> > > > > > > > tools for monitoring and management which will be useful for
> > our
> > > > > > > > end-users.
> > > > > > > >
> > > > > > > > But for continuing work we need to overcome this first phase.
> > > > > > > >
> > > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > > > questions.
> > > > > > > > Thanks!
> > > > > > > > >
> > > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > > dmekhanikov@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Guys,
> > > > > > > > > >
> > > > > > > > > > I'd like to take a look at the changes before they are
> > > merged.
> > > > > > > > > > I'll do my best to finish the review before the end of the
> > > > > upcoming
> > > > > > > > week.
> > > > > > > > > >
> > > > > > > > > > Thanks!
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > > nizhikov@apache.org
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Hello, Vladimir.
> > > > > > > > > > >
> > > > > > > > > > > I'm agree with you.
> > > > > > > > > > >
> > > > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > > > Without a date or similar.
> > > > > > > > > > > Just a list of experts who should review this feature.
> > > > > > > > > > >
> > > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > > > > > Igniters,
> > > > > > > > > > > >
> > > > > > > > > > > > This is very huge thing with complex algorithms behind.
> > > We
> > > > > > should
> > > > > > > > not
> > > > > > > > > > > merge
> > > > > > > > > > > > it to the product unless several additional thorough
> > > reviews
> > > > > > are
> > > > > > > > ready,
> > > > > > > > > > > > irrespectively of how long will it take. We are about
> > > > > quality,
> > > > > > > not
> > > > > > > > speed.
> > > > > > > > > > > >
> > > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > > dmagda@apache.org
> > > > > >:
> > > > > > > > > > > >
> > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > >
> > > > > > > > > > > > > What are the cases when the service can be
> > redeployed?
> > > > > > > Affinity,
> > > > > > > > > > > failure,
> > > > > > > > > > > > > etc., right. It would be good to list all the cases
> > on
> > > the
> > > > > > wiki
> > > > > > > > and
> > > > > > > > > > > then
> > > > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Services reassignment process takes into account
> > > previous
> > > > > > > > assignments
> > > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > > So, in the described case, ServiceA won't be moved
> > > from
> > > > > > node1
> > > > > > > > to
> > > > > > > > > > > node2.
> > > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > > > dmagda@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > First of all, thanks for archiving this milestone
> > > and
> > > > > > > > rolling out
> > > > > > > > > > > these
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > new
> > > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Speaking of the topology change events [1], does
> > > the
> > > > > new
> > > > > > > > > > > architecture
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > > a running service redeployment when a new node
> > > joins?
> > > > > For
> > > > > > > > instance,
> > > > > > > > > > > > >
> > > > > > > > > > > > > let's
> > > > > > > > > > > > > > > say I have ServiceA running node1, then node2
> > joins
> > > > > and I
> > > > > > > > don't
> > > > > > > > > > > want
> > > > > > > > > > > > >
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav
> > Daradur <
> > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi I think wiki is better than any attached
> > > docs.
> > > > > > Could
> > > > > > > > you
> > > > > > > > > > > please
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav
> > Daradur <
> > > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > :
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I prepared a description of the implemented
> > > > > > solution
> > > > > > > > and
> > > > > > > > > > > attached
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > This should help during a review. Should I
> > > post
> > > > > the
> > > > > > > > document
> > > > > > > > > > > into
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > > > > > solution
> > > > > > > > [1] [2],
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > [2]
> > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> > > > > Daradur
> > > > > > <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in
> > Patch
> > > > > > > > Available now.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > > implementation.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > However, we need additional review from
> > > other
> > > > > > > Ignite
> > > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR
> > [2].
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > [1]
> > > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > > [2]
> > > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > > > > > Mekhanikov <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> > > > > service
> > > > > > > > class name
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> > > > > Daradur
> > > > > > <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think that the replacement of
> > > serialized
> > > > > > > > instance
> > > > > > > > > > > makes
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > But how it should work for .NET
> > client?
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM
> > Dmitriy
> > > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM,
> > > Nikita
> > > > > > > > Amelchev <
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I am working on task [1] that
> > would
> > > > > > replace
> > > > > > > > > > > serialized
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > > by service's class name and
> > > properties
> > > > > > map
> > > > > > > in
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > The task describes that we should
> > > use
> > > > > > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> > > > > Object>
> > > > > > > > > > > properties}
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > > deprecated
> > > > > and
> > > > > > > use
> > > > > > > > class
> > > > > > > > > > > name
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > > Also to add deploying methods
> > with
> > > new
> > > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > Map<String,
> > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I think this makes sense, but I
> > would
> > > > > like
> > > > > > > > other
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> > > comment
> > > > > > here.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> > > properties}
> > > > > > > > parameter
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> > > > > methods
> > > > > > > > without
> > > > > > > > > > > it?
> > > > > > > > > > > > >
> > > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > > Map<String,
> > > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I would always ask the user to pass
> > > the
> > > > > > > > property
> > > > > > > > > > > map, but
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Vyacheslav,

Actually, the service assignment is implemented in a way,
that allows every node calculate the assignment itself, so no information
needs to be shared.
The only data, that is sent between nodes is deployment results,
and I don't see an analogy with exchange here.

Denis

ср, 21 нояб. 2018 г. в 11:16, Vladimir Ozerov <vo...@gridgain.com>:

> Hi Vyacheslav,
>
> Could you please explain in what situation coordinator needs to collect
> service deployments info from all nodes and share it with the cluster? I
> cannot remember from our design discussion when it is needed. Global state
> normally shared through discovery and only on node join, In this case we
> use "DiscoveryDataBags", not separate messages.
>
> On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > I think request-response is not suitable terms.
> >
> > Nodes send to coordinator maps of actual service deployments which
> > contains what count of instances of each service node hosts locally.
> >
> > Coordinator sends to the cluster the full map of deployments across the
> > cluster.
> >
> > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> > >
> > > I do not know what is correct term :-) What I said is that "exchange"
> is
> > > counter intuitive here. There is no "exchange", instead nodes send
> > > information to coordinator that they finished some operation. E.g. we
> do
> > > the same for schema changes (index creation), and as Denis suggested,
> > > Request-Response is correct suffixes here. Message name should explain
> > what
> > > really happened, instead of describing things which are somewhat
> similar
> > in
> > > internal flow.
> > >
> > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
> > > wrote:
> > >
> > > > Hello, Vladimir.
> > > >
> > > > What is correct term?
> > > >
> > > >
> > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
> > > >
> > > > > Agree. Service deployment has nothing to do with PME. We should not
> > use
> > > > the
> > > > > same term for different things.
> > > > >
> > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > dmekhanikov@gmail.com>:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > I'm in process of reviewing your changes. Sorry for taking so
> long.
> > > > > > I posted the first portion of review comments yesterday.
> > > > > > I'd like to finish looking through the code. I'll post more
> > comments
> > > > > later.
> > > > > >
> > > > > > I see, that you called things analogously to partition map
> > exchange.
> > > > > > I realize, that there is an analogy in used procedures, but I
> don't
> > > > > really
> > > > > > like the idea to use the same names for everything.
> > > > > > The partition map exchange is called this way because it involves
> > an
> > > > > actual
> > > > > > exchange of information.
> > > > > > All nodes need to tell each other, which partitions they have,
> and
> > what
> > > > > > their states are.
> > > > > >
> > > > > > There is no exchange in case of service deployment, so I would
> > skip the
> > > > > > "exchange" part.
> > > > > > And *single message ->* *full message* look more like *request ->
> > > > > response*
> > > > > > in case of services.
> > > > > >
> > > > > > Suppose we abandon the PME procedure and move to something else.
> > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > And I don't want to be in a situation, when I say to my
> colleague a
> > > > word
> > > > > > "exchange",
> > > > > > and get "which one?" in return.
> > > > > > So, I'm for the meaningful names rather than analogous to
> something
> > > > else.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > > >:
> > > > > >
> > > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > > >
> > > > > > > Igniters, we need to define a list of reviewers, otherwise no
> > end in
> > > > > > sign.
> > > > > > >
> > > > > > > I'm ready to continue work on the Service Grid, including new
> > > > features
> > > > > > > like hot-redeployment and versioning, also, I have ideas about
> > new
> > > > > > > tools for monitoring and management which will be useful for
> our
> > > > > > > end-users.
> > > > > > >
> > > > > > > But for continuing work we need to overcome this first phase.
> > > > > > >
> > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > > questions.
> > > > > > > Thanks!
> > > > > > > >
> > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > dmekhanikov@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > I'd like to take a look at the changes before they are
> > merged.
> > > > > > > > > I'll do my best to finish the review before the end of the
> > > > upcoming
> > > > > > > week.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > nizhikov@apache.org
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Hello, Vladimir.
> > > > > > > > > >
> > > > > > > > > > I'm agree with you.
> > > > > > > > > >
> > > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > > Without a date or similar.
> > > > > > > > > > Just a list of experts who should review this feature.
> > > > > > > > > >
> > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > > This is very huge thing with complex algorithms behind.
> > We
> > > > > should
> > > > > > > not
> > > > > > > > > > merge
> > > > > > > > > > > it to the product unless several additional thorough
> > reviews
> > > > > are
> > > > > > > ready,
> > > > > > > > > > > irrespectively of how long will it take. We are about
> > > > quality,
> > > > > > not
> > > > > > > speed.
> > > > > > > > > > >
> > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > dmagda@apache.org
> > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > >
> > > > > > > > > > > > What are the cases when the service can be
> redeployed?
> > > > > > Affinity,
> > > > > > > > > > failure,
> > > > > > > > > > > > etc., right. It would be good to list all the cases
> on
> > the
> > > > > wiki
> > > > > > > and
> > > > > > > > > > then
> > > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Denis,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Services reassignment process takes into account
> > previous
> > > > > > > assignments
> > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > So, in the described case, ServiceA won't be moved
> > from
> > > > > node1
> > > > > > > to
> > > > > > > > > > node2.
> > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > > dmagda@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > First of all, thanks for archiving this milestone
> > and
> > > > > > > rolling out
> > > > > > > > > > these
> > > > > > > > > > > > >
> > > > > > > > > > > > > new
> > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Speaking of the topology change events [1], does
> > the
> > > > new
> > > > > > > > > > architecture
> > > > > > > > > > > > >
> > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > a running service redeployment when a new node
> > joins?
> > > > For
> > > > > > > instance,
> > > > > > > > > > > >
> > > > > > > > > > > > let's
> > > > > > > > > > > > > > say I have ServiceA running node1, then node2
> joins
> > > > and I
> > > > > > > don't
> > > > > > > > > > want
> > > > > > > > > > > >
> > > > > > > > > > > > the
> > > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav
> Daradur <
> > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi I think wiki is better than any attached
> > docs.
> > > > > Could
> > > > > > > you
> > > > > > > > > > please
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav
> Daradur <
> > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > :
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I prepared a description of the implemented
> > > > > solution
> > > > > > > and
> > > > > > > > > > attached
> > > > > > > > > > > > >
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This should help during a review. Should I
> > post
> > > > the
> > > > > > > document
> > > > > > > > > > into
> > > > > > > > > > > > >
> > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > > > > solution
> > > > > > > [1] [2],
> > > > > > > > > > > > >
> > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > [2]
> > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> > > > Daradur
> > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in
> Patch
> > > > > > > Available now.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > implementation.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > However, we need additional review from
> > other
> > > > > > Ignite
> > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR
> [2].
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > [2]
> > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > > > > Mekhanikov <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> > > > service
> > > > > > > class name
> > > > > > > > > > > > >
> > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> > > > Daradur
> > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think that the replacement of
> > serialized
> > > > > > > instance
> > > > > > > > > > makes
> > > > > > > > > > > > >
> > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But how it should work for .NET
> client?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM
> Dmitriy
> > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM,
> > Nikita
> > > > > > > Amelchev <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I am working on task [1] that
> would
> > > > > replace
> > > > > > > > > > serialized
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > by service's class name and
> > properties
> > > > > map
> > > > > > in
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The task describes that we should
> > use
> > > > > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> > > > Object>
> > > > > > > > > > properties}
> > > > > > > > > > > > >
> > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > deprecated
> > > > and
> > > > > > use
> > > > > > > class
> > > > > > > > > > name
> > > > > > > > > > > > >
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > Also to add deploying methods
> with
> > new
> > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > Map<String,
> > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think this makes sense, but I
> would
> > > > like
> > > > > > > other
> > > > > > > > > > > > >
> > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> > comment
> > > > > here.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> > properties}
> > > > > > > parameter
> > > > > > > > > > > > >
> > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> > > > methods
> > > > > > > without
> > > > > > > > > > it?
> > > > > > > > > > > >
> > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > Map<String,
> > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I would always ask the user to pass
> > the
> > > > > > > property
> > > > > > > > > > map, but
> > > > > > > > > > > > >
> > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
During each deployment (exchange) process nodes send to the
coordinator (p2p) deployments maps, caused:
- users requests (deploy/undeploy)
- affinity change (if affinity services present)
- topology change (if services present)
- activation (if services descriptors present)

Also, single node deployment results contain deployment errors which
aggregate by coordinator and propagates across the cluster. And this
is important for introduced service deployment failures policy.

Please, see document for details:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
On Wed, Nov 21, 2018 at 11:16 AM Vladimir Ozerov <vo...@gridgain.com> wrote:
>
> Hi Vyacheslav,
>
> Could you please explain in what situation coordinator needs to collect
> service deployments info from all nodes and share it with the cluster? I
> cannot remember from our design discussion when it is needed. Global state
> normally shared through discovery and only on node join, In this case we
> use "DiscoveryDataBags", not separate messages.
>
> On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > I think request-response is not suitable terms.
> >
> > Nodes send to coordinator maps of actual service deployments which
> > contains what count of instances of each service node hosts locally.
> >
> > Coordinator sends to the cluster the full map of deployments across the
> > cluster.
> >
> > On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <vo...@gridgain.com>
> > wrote:
> > >
> > > I do not know what is correct term :-) What I said is that "exchange" is
> > > counter intuitive here. There is no "exchange", instead nodes send
> > > information to coordinator that they finished some operation. E.g. we do
> > > the same for schema changes (index creation), and as Denis suggested,
> > > Request-Response is correct suffixes here. Message name should explain
> > what
> > > really happened, instead of describing things which are somewhat similar
> > in
> > > internal flow.
> > >
> > > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
> > > wrote:
> > >
> > > > Hello, Vladimir.
> > > >
> > > > What is correct term?
> > > >
> > > >
> > > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
> > > >
> > > > > Agree. Service deployment has nothing to do with PME. We should not
> > use
> > > > the
> > > > > same term for different things.
> > > > >
> > > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> > dmekhanikov@gmail.com>:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > > > > I posted the first portion of review comments yesterday.
> > > > > > I'd like to finish looking through the code. I'll post more
> > comments
> > > > > later.
> > > > > >
> > > > > > I see, that you called things analogously to partition map
> > exchange.
> > > > > > I realize, that there is an analogy in used procedures, but I don't
> > > > > really
> > > > > > like the idea to use the same names for everything.
> > > > > > The partition map exchange is called this way because it involves
> > an
> > > > > actual
> > > > > > exchange of information.
> > > > > > All nodes need to tell each other, which partitions they have, and
> > what
> > > > > > their states are.
> > > > > >
> > > > > > There is no exchange in case of service deployment, so I would
> > skip the
> > > > > > "exchange" part.
> > > > > > And *single message ->* *full message* look more like *request ->
> > > > > response*
> > > > > > in case of services.
> > > > > >
> > > > > > Suppose we abandon the PME procedure and move to something else.
> > > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > > And I don't want to be in a situation, when I say to my colleague a
> > > > word
> > > > > > "exchange",
> > > > > > and get "which one?" in return.
> > > > > > So, I'm for the meaningful names rather than analogous to something
> > > > else.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > > >:
> > > > > >
> > > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > > >
> > > > > > > Igniters, we need to define a list of reviewers, otherwise no
> > end in
> > > > > > sign.
> > > > > > >
> > > > > > > I'm ready to continue work on the Service Grid, including new
> > > > features
> > > > > > > like hot-redeployment and versioning, also, I have ideas about
> > new
> > > > > > > tools for monitoring and management which will be useful for our
> > > > > > > end-users.
> > > > > > >
> > > > > > > But for continuing work we need to overcome this first phase.
> > > > > > >
> > > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > > questions.
> > > > > > > Thanks!
> > > > > > > >
> > > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > > dmekhanikov@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Guys,
> > > > > > > > >
> > > > > > > > > I'd like to take a look at the changes before they are
> > merged.
> > > > > > > > > I'll do my best to finish the review before the end of the
> > > > upcoming
> > > > > > > week.
> > > > > > > > >
> > > > > > > > > Thanks!
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > > nizhikov@apache.org
> > > > > >:
> > > > > > > > >
> > > > > > > > > > Hello, Vladimir.
> > > > > > > > > >
> > > > > > > > > > I'm agree with you.
> > > > > > > > > >
> > > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > > Without a date or similar.
> > > > > > > > > > Just a list of experts who should review this feature.
> > > > > > > > > >
> > > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > > > > Igniters,
> > > > > > > > > > >
> > > > > > > > > > > This is very huge thing with complex algorithms behind.
> > We
> > > > > should
> > > > > > > not
> > > > > > > > > > merge
> > > > > > > > > > > it to the product unless several additional thorough
> > reviews
> > > > > are
> > > > > > > ready,
> > > > > > > > > > > irrespectively of how long will it take. We are about
> > > > quality,
> > > > > > not
> > > > > > > speed.
> > > > > > > > > > >
> > > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> > dmagda@apache.org
> > > > >:
> > > > > > > > > > >
> > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > >
> > > > > > > > > > > > What are the cases when the service can be redeployed?
> > > > > > Affinity,
> > > > > > > > > > failure,
> > > > > > > > > > > > etc., right. It would be good to list all the cases on
> > the
> > > > > wiki
> > > > > > > and
> > > > > > > > > > then
> > > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Denis,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Services reassignment process takes into account
> > previous
> > > > > > > assignments
> > > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > > So, in the described case, ServiceA won't be moved
> > from
> > > > > node1
> > > > > > > to
> > > > > > > > > > node2.
> > > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > > dmagda@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > First of all, thanks for archiving this milestone
> > and
> > > > > > > rolling out
> > > > > > > > > > these
> > > > > > > > > > > > >
> > > > > > > > > > > > > new
> > > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Speaking of the topology change events [1], does
> > the
> > > > new
> > > > > > > > > > architecture
> > > > > > > > > > > > >
> > > > > > > > > > > > > avoid
> > > > > > > > > > > > > > a running service redeployment when a new node
> > joins?
> > > > For
> > > > > > > instance,
> > > > > > > > > > > >
> > > > > > > > > > > > let's
> > > > > > > > > > > > > > say I have ServiceA running node1, then node2 joins
> > > > and I
> > > > > > > don't
> > > > > > > > > > want
> > > > > > > > > > > >
> > > > > > > > > > > > the
> > > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi I think wiki is better than any attached
> > docs.
> > > > > Could
> > > > > > > you
> > > > > > > > > > please
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > :
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I prepared a description of the implemented
> > > > > solution
> > > > > > > and
> > > > > > > > > > attached
> > > > > > > > > > > > >
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > This should help during a review. Should I
> > post
> > > > the
> > > > > > > document
> > > > > > > > > > into
> > > > > > > > > > > > >
> > > > > > > > > > > > > wiki
> > > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > > > > solution
> > > > > > > [1] [2],
> > > > > > > > > > > > >
> > > > > > > > > > > > > please?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > [2]
> > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> > > > Daradur
> > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > > > > Available now.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> > implementation.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > However, we need additional review from
> > other
> > > > > > Ignite
> > > > > > > > > > experts.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > [1]
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > > [2]
> > https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > > > > Mekhanikov <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> > > > service
> > > > > > > class name
> > > > > > > > > > > > >
> > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> > > > Daradur
> > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think that the replacement of
> > serialized
> > > > > > > instance
> > > > > > > > > > makes
> > > > > > > > > > > > >
> > > > > > > > > > > > > sense
> > > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > > > > Setrakyan <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM,
> > Nikita
> > > > > > > Amelchev <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > > > > replace
> > > > > > > > > > serialized
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > > by service's class name and
> > properties
> > > > > map
> > > > > > in
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > The task describes that we should
> > use
> > > > > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> > > > Object>
> > > > > > > > > > properties}
> > > > > > > > > > > > >
> > > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > > > > questions:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> > deprecated
> > > > and
> > > > > > use
> > > > > > > class
> > > > > > > > > > name
> > > > > > > > > > > > >
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > > Also to add deploying methods with
> > new
> > > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > Map<String,
> > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I think this makes sense, but I would
> > > > like
> > > > > > > other
> > > > > > > > > > > > >
> > > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> > comment
> > > > > here.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> > properties}
> > > > > > > parameter
> > > > > > > > > > > > >
> > > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> > > > methods
> > > > > > > without
> > > > > > > > > > it?
> > > > > > > > > > > >
> > > > > > > > > > > > For
> > > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> > Map<String,
> > > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I would always ask the user to pass
> > the
> > > > > > > property
> > > > > > > > > > map, but
> > > > > > > > > > > > >
> > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 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.
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
Hi Vyacheslav,

Could you please explain in what situation coordinator needs to collect
service deployments info from all nodes and share it with the cluster? I
cannot remember from our design discussion when it is needed. Global state
normally shared through discovery and only on node join, In this case we
use "DiscoveryDataBags", not separate messages.

On Wed, Nov 21, 2018 at 11:11 AM Vyacheslav Daradur <da...@gmail.com>
wrote:

> I think request-response is not suitable terms.
>
> Nodes send to coordinator maps of actual service deployments which
> contains what count of instances of each service node hosts locally.
>
> Coordinator sends to the cluster the full map of deployments across the
> cluster.
>
> On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <vo...@gridgain.com>
> wrote:
> >
> > I do not know what is correct term :-) What I said is that "exchange" is
> > counter intuitive here. There is no "exchange", instead nodes send
> > information to coordinator that they finished some operation. E.g. we do
> > the same for schema changes (index creation), and as Denis suggested,
> > Request-Response is correct suffixes here. Message name should explain
> what
> > really happened, instead of describing things which are somewhat similar
> in
> > internal flow.
> >
> > On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
> > wrote:
> >
> > > Hello, Vladimir.
> > >
> > > What is correct term?
> > >
> > >
> > > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
> > >
> > > > Agree. Service deployment has nothing to do with PME. We should not
> use
> > > the
> > > > same term for different things.
> > > >
> > > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <
> dmekhanikov@gmail.com>:
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > > > I posted the first portion of review comments yesterday.
> > > > > I'd like to finish looking through the code. I'll post more
> comments
> > > > later.
> > > > >
> > > > > I see, that you called things analogously to partition map
> exchange.
> > > > > I realize, that there is an analogy in used procedures, but I don't
> > > > really
> > > > > like the idea to use the same names for everything.
> > > > > The partition map exchange is called this way because it involves
> an
> > > > actual
> > > > > exchange of information.
> > > > > All nodes need to tell each other, which partitions they have, and
> what
> > > > > their states are.
> > > > >
> > > > > There is no exchange in case of service deployment, so I would
> skip the
> > > > > "exchange" part.
> > > > > And *single message ->* *full message* look more like *request ->
> > > > response*
> > > > > in case of services.
> > > > >
> > > > > Suppose we abandon the PME procedure and move to something else.
> > > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > > And I don't want to be in a situation, when I say to my colleague a
> > > word
> > > > > "exchange",
> > > > > and get "which one?" in return.
> > > > > So, I'm for the meaningful names rather than analogous to something
> > > else.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Denis
> > > > >
> > > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <
> daradurvs@gmail.com
> > > >:
> > > > >
> > > > > > Denis, Yakov have you had a chance to review the solution?
> > > > > >
> > > > > > Igniters, we need to define a list of reviewers, otherwise no
> end in
> > > > > sign.
> > > > > >
> > > > > > I'm ready to continue work on the Service Grid, including new
> > > features
> > > > > > like hot-redeployment and versioning, also, I have ideas about
> new
> > > > > > tools for monitoring and management which will be useful for our
> > > > > > end-users.
> > > > > >
> > > > > > But for continuing work we need to overcome this first phase.
> > > > > >
> > > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > > daradurvs@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Denis, Yakov, feel free to contact me directly in case of
> > > questions.
> > > > > > Thanks!
> > > > > > >
> > > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > > dmekhanikov@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Guys,
> > > > > > > >
> > > > > > > > I'd like to take a look at the changes before they are
> merged.
> > > > > > > > I'll do my best to finish the review before the end of the
> > > upcoming
> > > > > > week.
> > > > > > > >
> > > > > > > > Thanks!
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > > nizhikov@apache.org
> > > > >:
> > > > > > > >
> > > > > > > > > Hello, Vladimir.
> > > > > > > > >
> > > > > > > > > I'm agree with you.
> > > > > > > > >
> > > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > > Without a date or similar.
> > > > > > > > > Just a list of experts who should review this feature.
> > > > > > > > >
> > > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > > > Igniters,
> > > > > > > > > >
> > > > > > > > > > This is very huge thing with complex algorithms behind.
> We
> > > > should
> > > > > > not
> > > > > > > > > merge
> > > > > > > > > > it to the product unless several additional thorough
> reviews
> > > > are
> > > > > > ready,
> > > > > > > > > > irrespectively of how long will it take. We are about
> > > quality,
> > > > > not
> > > > > > speed.
> > > > > > > > > >
> > > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <
> dmagda@apache.org
> > > >:
> > > > > > > > > >
> > > > > > > > > > > Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > What are the cases when the service can be redeployed?
> > > > > Affinity,
> > > > > > > > > failure,
> > > > > > > > > > > etc., right. It would be good to list all the cases on
> the
> > > > wiki
> > > > > > and
> > > > > > > > > then
> > > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Denis,
> > > > > > > > > > > >
> > > > > > > > > > > > Services reassignment process takes into account
> previous
> > > > > > assignments
> > > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > > So, in the described case, ServiceA won't be moved
> from
> > > > node1
> > > > > > to
> > > > > > > > > node2.
> > > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > > dmagda@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > > >
> > > > > > > > > > > > > First of all, thanks for archiving this milestone
> and
> > > > > > rolling out
> > > > > > > > > these
> > > > > > > > > > > >
> > > > > > > > > > > > new
> > > > > > > > > > > > > capabilities.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Speaking of the topology change events [1], does
> the
> > > new
> > > > > > > > > architecture
> > > > > > > > > > > >
> > > > > > > > > > > > avoid
> > > > > > > > > > > > > a running service redeployment when a new node
> joins?
> > > For
> > > > > > instance,
> > > > > > > > > > >
> > > > > > > > > > > let's
> > > > > > > > > > > > > say I have ServiceA running node1, then node2 joins
> > > and I
> > > > > > don't
> > > > > > > > > want
> > > > > > > > > > >
> > > > > > > > > > > the
> > > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi I think wiki is better than any attached
> docs.
> > > > Could
> > > > > > you
> > > > > > > > > please
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > create a
> > > > > > > > > > > > > > > page?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > :
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I prepared a description of the implemented
> > > > solution
> > > > > > and
> > > > > > > > > attached
> > > > > > > > > > > >
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This should help during a review. Should I
> post
> > > the
> > > > > > document
> > > > > > > > > into
> > > > > > > > > > > >
> > > > > > > > > > > > wiki
> > > > > > > > > > > > > > or
> > > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > > > solution
> > > > > > [1] [2],
> > > > > > > > > > > >
> > > > > > > > > > > > please?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > [2]
> https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> > > Daradur
> > > > <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > > > Available now.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed
> implementation.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > However, we need additional review from
> other
> > > > > Ignite
> > > > > > > > > experts.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > [1]
> > > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > > [2]
> https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > > > Mekhanikov <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> > > service
> > > > > > class name
> > > > > > > > > > > >
> > > > > > > > > > > > instead
> > > > > > > > > > > > > > of
> > > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> > > Daradur
> > > > <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think that the replacement of
> serialized
> > > > > > instance
> > > > > > > > > makes
> > > > > > > > > > > >
> > > > > > > > > > > > sense
> > > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > > > Setrakyan <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM,
> Nikita
> > > > > > Amelchev <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > > > replace
> > > > > > > > > serialized
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > > by service's class name and
> properties
> > > > map
> > > > > in
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > The task describes that we should
> use
> > > > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> > > Object>
> > > > > > > > > properties}
> > > > > > > > > > > >
> > > > > > > > > > > > instead
> > > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > > > questions:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > > I suggest to mark them as
> deprecated
> > > and
> > > > > use
> > > > > > class
> > > > > > > > > name
> > > > > > > > > > > >
> > > > > > > > > > > > of
> > > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > > Also to add deploying methods with
> new
> > > > > > parameters:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> Map<String,
> > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I think this makes sense, but I would
> > > like
> > > > > > other
> > > > > > > > > > > >
> > > > > > > > > > > > committers to
> > > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should
> comment
> > > > here.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object>
> properties}
> > > > > > parameter
> > > > > > > > > > > >
> > > > > > > > > > > > mandatory
> > > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> > > methods
> > > > > > without
> > > > > > > > > it?
> > > > > > > > > > >
> > > > > > > > > > > For
> > > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > > name, String srvcClsName,
> Map<String,
> > > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I would always ask the user to pass
> the
> > > > > > property
> > > > > > > > > map, but
> > > > > > > > > > > >
> > > > > > > > > > > > would
> > > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
I think request-response is not suitable terms.

Nodes send to coordinator maps of actual service deployments which
contains what count of instances of each service node hosts locally.

Coordinator sends to the cluster the full map of deployments across the cluster.

On Wed, Nov 21, 2018 at 11:04 AM Vladimir Ozerov <vo...@gridgain.com> wrote:
>
> I do not know what is correct term :-) What I said is that "exchange" is
> counter intuitive here. There is no "exchange", instead nodes send
> information to coordinator that they finished some operation. E.g. we do
> the same for schema changes (index creation), and as Denis suggested,
> Request-Response is correct suffixes here. Message name should explain what
> really happened, instead of describing things which are somewhat similar in
> internal flow.
>
> On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
> wrote:
>
> > Hello, Vladimir.
> >
> > What is correct term?
> >
> >
> > ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
> >
> > > Agree. Service deployment has nothing to do with PME. We should not use
> > the
> > > same term for different things.
> > >
> > > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:
> > >
> > > > Vyacheslav,
> > > >
> > > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > > I posted the first portion of review comments yesterday.
> > > > I'd like to finish looking through the code. I'll post more comments
> > > later.
> > > >
> > > > I see, that you called things analogously to partition map exchange.
> > > > I realize, that there is an analogy in used procedures, but I don't
> > > really
> > > > like the idea to use the same names for everything.
> > > > The partition map exchange is called this way because it involves an
> > > actual
> > > > exchange of information.
> > > > All nodes need to tell each other, which partitions they have, and what
> > > > their states are.
> > > >
> > > > There is no exchange in case of service deployment, so I would skip the
> > > > "exchange" part.
> > > > And *single message ->* *full message* look more like *request ->
> > > response*
> > > > in case of services.
> > > >
> > > > Suppose we abandon the PME procedure and move to something else.
> > > > Then *ServiceDeploymentExchange* name won't make sense.
> > > > And I don't want to be in a situation, when I say to my colleague a
> > word
> > > > "exchange",
> > > > and get "which one?" in return.
> > > > So, I'm for the meaningful names rather than analogous to something
> > else.
> > > >
> > > > What do you think?
> > > >
> > > > Denis
> > > >
> > > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <daradurvs@gmail.com
> > >:
> > > >
> > > > > Denis, Yakov have you had a chance to review the solution?
> > > > >
> > > > > Igniters, we need to define a list of reviewers, otherwise no end in
> > > > sign.
> > > > >
> > > > > I'm ready to continue work on the Service Grid, including new
> > features
> > > > > like hot-redeployment and versioning, also, I have ideas about new
> > > > > tools for monitoring and management which will be useful for our
> > > > > end-users.
> > > > >
> > > > > But for continuing work we need to overcome this first phase.
> > > > >
> > > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > > daradurvs@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Denis, Yakov, feel free to contact me directly in case of
> > questions.
> > > > > Thanks!
> > > > > >
> > > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > > dmekhanikov@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Guys,
> > > > > > >
> > > > > > > I'd like to take a look at the changes before they are merged.
> > > > > > > I'll do my best to finish the review before the end of the
> > upcoming
> > > > > week.
> > > > > > >
> > > > > > > Thanks!
> > > > > > > Denis
> > > > > > >
> > > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> > nizhikov@apache.org
> > > >:
> > > > > > >
> > > > > > > > Hello, Vladimir.
> > > > > > > >
> > > > > > > > I'm agree with you.
> > > > > > > >
> > > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > > Without a date or similar.
> > > > > > > > Just a list of experts who should review this feature.
> > > > > > > >
> > > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > This is very huge thing with complex algorithms behind. We
> > > should
> > > > > not
> > > > > > > > merge
> > > > > > > > > it to the product unless several additional thorough reviews
> > > are
> > > > > ready,
> > > > > > > > > irrespectively of how long will it take. We are about
> > quality,
> > > > not
> > > > > speed.
> > > > > > > > >
> > > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dmagda@apache.org
> > >:
> > > > > > > > >
> > > > > > > > > > Vyacheslav,
> > > > > > > > > >
> > > > > > > > > > What are the cases when the service can be redeployed?
> > > > Affinity,
> > > > > > > > failure,
> > > > > > > > > > etc., right. It would be good to list all the cases on the
> > > wiki
> > > > > and
> > > > > > > > then
> > > > > > > > > > our tech writers will get everything documented.
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Denis,
> > > > > > > > > > >
> > > > > > > > > > > Services reassignment process takes into account previous
> > > > > assignments
> > > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > > So, in the described case, ServiceA won't be moved from
> > > node1
> > > > > to
> > > > > > > > node2.
> > > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > > dmagda@apache.org>
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Vyacheslav,
> > > > > > > > > > > >
> > > > > > > > > > > > First of all, thanks for archiving this milestone and
> > > > > rolling out
> > > > > > > > these
> > > > > > > > > > >
> > > > > > > > > > > new
> > > > > > > > > > > > capabilities.
> > > > > > > > > > > >
> > > > > > > > > > > > Speaking of the topology change events [1], does the
> > new
> > > > > > > > architecture
> > > > > > > > > > >
> > > > > > > > > > > avoid
> > > > > > > > > > > > a running service redeployment when a new node joins?
> > For
> > > > > instance,
> > > > > > > > > >
> > > > > > > > > > let's
> > > > > > > > > > > > say I have ServiceA running node1, then node2 joins
> > and I
> > > > > don't
> > > > > > > > want
> > > > > > > > > >
> > > > > > > > > > the
> > > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > > daradurvs@gmail.com
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > > >
> > > > > > > > > > > > > Thank you!
> > > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi I think wiki is better than any attached docs.
> > > Could
> > > > > you
> > > > > > > > please
> > > > > > > > > > > > >
> > > > > > > > > > > > > create a
> > > > > > > > > > > > > > page?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > > daradurvs@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > :
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I prepared a description of the implemented
> > > solution
> > > > > and
> > > > > > > > attached
> > > > > > > > > > >
> > > > > > > > > > > it
> > > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This should help during a review. Should I post
> > the
> > > > > document
> > > > > > > > into
> > > > > > > > > > >
> > > > > > > > > > > wiki
> > > > > > > > > > > > > or
> > > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > > solution
> > > > > [1] [2],
> > > > > > > > > > >
> > > > > > > > > > > please?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> > Daradur
> > > <
> > > > > > > > > > > > >
> > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > > Available now.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > However, we need additional review from other
> > > > Ignite
> > > > > > > > experts.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> > > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > > Mekhanikov <
> > > > > > > > > > > > >
> > > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> > service
> > > > > class name
> > > > > > > > > > >
> > > > > > > > > > > instead
> > > > > > > > > > > > > of
> > > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> > Daradur
> > > <
> > > > > > > > > > > > >
> > > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think that the replacement of serialized
> > > > > instance
> > > > > > > > makes
> > > > > > > > > > >
> > > > > > > > > > > sense
> > > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > > Setrakyan <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > > > > Amelchev <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > > replace
> > > > > > > > serialized
> > > > > > > > > > > > >
> > > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > > by service's class name and properties
> > > map
> > > > in
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> > Object>
> > > > > > > > properties}
> > > > > > > > > > >
> > > > > > > > > > > instead
> > > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > > questions:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > > I suggest to mark them as deprecated
> > and
> > > > use
> > > > > class
> > > > > > > > name
> > > > > > > > > > >
> > > > > > > > > > > of
> > > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > > > > parameters:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > >
> > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > >
> > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I think this makes sense, but I would
> > like
> > > > > other
> > > > > > > > > > >
> > > > > > > > > > > committers to
> > > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment
> > > here.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > > > > parameter
> > > > > > > > > > >
> > > > > > > > > > > mandatory
> > > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> > methods
> > > > > without
> > > > > > > > it?
> > > > > > > > > >
> > > > > > > > > > For
> > > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > >
> > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > > >
> > > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > > Object> prop)
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I would always ask the user to pass the
> > > > > property
> > > > > > > > map, but
> > > > > > > > > > >
> > > > > > > > > > > would
> > > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 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.
> > > > >
> > > >
> > >
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
I do not know what is correct term :-) What I said is that "exchange" is
counter intuitive here. There is no "exchange", instead nodes send
information to coordinator that they finished some operation. E.g. we do
the same for schema changes (index creation), and as Denis suggested,
Request-Response is correct suffixes here. Message name should explain what
really happened, instead of describing things which are somewhat similar in
internal flow.

On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org>
wrote:

> Hello, Vladimir.
>
> What is correct term?
>
>
> ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
>
> > Agree. Service deployment has nothing to do with PME. We should not use
> the
> > same term for different things.
> >
> > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:
> >
> > > Vyacheslav,
> > >
> > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > I posted the first portion of review comments yesterday.
> > > I'd like to finish looking through the code. I'll post more comments
> > later.
> > >
> > > I see, that you called things analogously to partition map exchange.
> > > I realize, that there is an analogy in used procedures, but I don't
> > really
> > > like the idea to use the same names for everything.
> > > The partition map exchange is called this way because it involves an
> > actual
> > > exchange of information.
> > > All nodes need to tell each other, which partitions they have, and what
> > > their states are.
> > >
> > > There is no exchange in case of service deployment, so I would skip the
> > > "exchange" part.
> > > And *single message ->* *full message* look more like *request ->
> > response*
> > > in case of services.
> > >
> > > Suppose we abandon the PME procedure and move to something else.
> > > Then *ServiceDeploymentExchange* name won't make sense.
> > > And I don't want to be in a situation, when I say to my colleague a
> word
> > > "exchange",
> > > and get "which one?" in return.
> > > So, I'm for the meaningful names rather than analogous to something
> else.
> > >
> > > What do you think?
> > >
> > > Denis
> > >
> > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <daradurvs@gmail.com
> >:
> > >
> > > > Denis, Yakov have you had a chance to review the solution?
> > > >
> > > > Igniters, we need to define a list of reviewers, otherwise no end in
> > > sign.
> > > >
> > > > I'm ready to continue work on the Service Grid, including new
> features
> > > > like hot-redeployment and versioning, also, I have ideas about new
> > > > tools for monitoring and management which will be useful for our
> > > > end-users.
> > > >
> > > > But for continuing work we need to overcome this first phase.
> > > >
> > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > >
> > > > > Denis, Yakov, feel free to contact me directly in case of
> questions.
> > > > Thanks!
> > > > >
> > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Guys,
> > > > > >
> > > > > > I'd like to take a look at the changes before they are merged.
> > > > > > I'll do my best to finish the review before the end of the
> upcoming
> > > > week.
> > > > > >
> > > > > > Thanks!
> > > > > > Denis
> > > > > >
> > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <
> nizhikov@apache.org
> > >:
> > > > > >
> > > > > > > Hello, Vladimir.
> > > > > > >
> > > > > > > I'm agree with you.
> > > > > > >
> > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > Without a date or similar.
> > > > > > > Just a list of experts who should review this feature.
> > > > > > >
> > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > This is very huge thing with complex algorithms behind. We
> > should
> > > > not
> > > > > > > merge
> > > > > > > > it to the product unless several additional thorough reviews
> > are
> > > > ready,
> > > > > > > > irrespectively of how long will it take. We are about
> quality,
> > > not
> > > > speed.
> > > > > > > >
> > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dmagda@apache.org
> >:
> > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > What are the cases when the service can be redeployed?
> > > Affinity,
> > > > > > > failure,
> > > > > > > > > etc., right. It would be good to list all the cases on the
> > wiki
> > > > and
> > > > > > > then
> > > > > > > > > our tech writers will get everything documented.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > Services reassignment process takes into account previous
> > > > assignments
> > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > So, in the described case, ServiceA won't be moved from
> > node1
> > > > to
> > > > > > > node2.
> > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > dmagda@apache.org>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > First of all, thanks for archiving this milestone and
> > > > rolling out
> > > > > > > these
> > > > > > > > > >
> > > > > > > > > > new
> > > > > > > > > > > capabilities.
> > > > > > > > > > >
> > > > > > > > > > > Speaking of the topology change events [1], does the
> new
> > > > > > > architecture
> > > > > > > > > >
> > > > > > > > > > avoid
> > > > > > > > > > > a running service redeployment when a new node joins?
> For
> > > > instance,
> > > > > > > > >
> > > > > > > > > let's
> > > > > > > > > > > say I have ServiceA running node1, then node2 joins
> and I
> > > > don't
> > > > > > > want
> > > > > > > > >
> > > > > > > > > the
> > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you!
> > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi I think wiki is better than any attached docs.
> > Could
> > > > you
> > > > > > > please
> > > > > > > > > > > >
> > > > > > > > > > > > create a
> > > > > > > > > > > > > page?
> > > > > > > > > > > > >
> > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > >
> > > > > > > > > > :
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I prepared a description of the implemented
> > solution
> > > > and
> > > > > > > attached
> > > > > > > > > >
> > > > > > > > > > it
> > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This should help during a review. Should I post
> the
> > > > document
> > > > > > > into
> > > > > > > > > >
> > > > > > > > > > wiki
> > > > > > > > > > > > or
> > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > solution
> > > > [1] [2],
> > > > > > > > > >
> > > > > > > > > > please?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav
> Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > Available now.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > However, we need additional review from other
> > > Ignite
> > > > > > > experts.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > Mekhanikov <
> > > > > > > > > > > >
> > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does it make sense for .Net to specify
> service
> > > > class name
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > of
> > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav
> Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think that the replacement of serialized
> > > > instance
> > > > > > > makes
> > > > > > > > > >
> > > > > > > > > > sense
> > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > Setrakyan <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > > > Amelchev <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > replace
> > > > > > > serialized
> > > > > > > > > > > >
> > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > by service's class name and properties
> > map
> > > in
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > > > {String className} + {Map<String,
> Object>
> > > > > > > properties}
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > questions:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > I suggest to mark them as deprecated
> and
> > > use
> > > > class
> > > > > > > name
> > > > > > > > > >
> > > > > > > > > > of
> > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > > > parameters:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think this makes sense, but I would
> like
> > > > other
> > > > > > > > > >
> > > > > > > > > > committers to
> > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment
> > here.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > > > parameter
> > > > > > > > > >
> > > > > > > > > > mandatory
> > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > Is it make sense to add deploying
> methods
> > > > without
> > > > > > > it?
> > > > > > > > >
> > > > > > > > > For
> > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I would always ask the user to pass the
> > > > property
> > > > > > > map, but
> > > > > > > > > >
> > > > > > > > > > would
> > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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.
> > > >
> > >
> >
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
First, we must agree on names.

I think the valuable word is 'deployment', though 'exchange' may be
used too because there is an exchange of deployments maps during the
deployment process.

To avoid intersections with PME I suggest using the following names:

ServicesFullMapMessage -> ServicesFullDeploymentsMessage
ServicesSingleMapMessage -> ServicesSingleDeploymentsMessage
ServicesExchangeActions -> ServicesDeploymentActions
ServicesDeploymentExchangeId -> ServicesDeploymentId
ServicesDeploymentExchangeTask -> ServicesDeploymentTask
ServicesDeploymentExchangeWorker -> ServicesDeploymentWorker
ServicesDeploymentExchangeManager -> ServicesDeploymentManager
On Wed, Nov 21, 2018 at 10:49 AM Nikolay Izhikov <ni...@apache.org> wrote:
>
> Hello, Vladimir.
>
> What is correct term?
>
>
> ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:
>
> > Agree. Service deployment has nothing to do with PME. We should not use the
> > same term for different things.
> >
> > вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:
> >
> > > Vyacheslav,
> > >
> > > I'm in process of reviewing your changes. Sorry for taking so long.
> > > I posted the first portion of review comments yesterday.
> > > I'd like to finish looking through the code. I'll post more comments
> > later.
> > >
> > > I see, that you called things analogously to partition map exchange.
> > > I realize, that there is an analogy in used procedures, but I don't
> > really
> > > like the idea to use the same names for everything.
> > > The partition map exchange is called this way because it involves an
> > actual
> > > exchange of information.
> > > All nodes need to tell each other, which partitions they have, and what
> > > their states are.
> > >
> > > There is no exchange in case of service deployment, so I would skip the
> > > "exchange" part.
> > > And *single message ->* *full message* look more like *request ->
> > response*
> > > in case of services.
> > >
> > > Suppose we abandon the PME procedure and move to something else.
> > > Then *ServiceDeploymentExchange* name won't make sense.
> > > And I don't want to be in a situation, when I say to my colleague a word
> > > "exchange",
> > > and get "which one?" in return.
> > > So, I'm for the meaningful names rather than analogous to something else.
> > >
> > > What do you think?
> > >
> > > Denis
> > >
> > > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > Denis, Yakov have you had a chance to review the solution?
> > > >
> > > > Igniters, we need to define a list of reviewers, otherwise no end in
> > > sign.
> > > >
> > > > I'm ready to continue work on the Service Grid, including new features
> > > > like hot-redeployment and versioning, also, I have ideas about new
> > > > tools for monitoring and management which will be useful for our
> > > > end-users.
> > > >
> > > > But for continuing work we need to overcome this first phase.
> > > >
> > > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > >
> > > > > Denis, Yakov, feel free to contact me directly in case of questions.
> > > > Thanks!
> > > > >
> > > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Guys,
> > > > > >
> > > > > > I'd like to take a look at the changes before they are merged.
> > > > > > I'll do my best to finish the review before the end of the upcoming
> > > > week.
> > > > > >
> > > > > > Thanks!
> > > > > > Denis
> > > > > >
> > > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <nizhikov@apache.org
> > >:
> > > > > >
> > > > > > > Hello, Vladimir.
> > > > > > >
> > > > > > > I'm agree with you.
> > > > > > >
> > > > > > > Can we write the list of reviewers for this feature?
> > > > > > > Without a date or similar.
> > > > > > > Just a list of experts who should review this feature.
> > > > > > >
> > > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > This is very huge thing with complex algorithms behind. We
> > should
> > > > not
> > > > > > > merge
> > > > > > > > it to the product unless several additional thorough reviews
> > are
> > > > ready,
> > > > > > > > irrespectively of how long will it take. We are about quality,
> > > not
> > > > speed.
> > > > > > > >
> > > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > What are the cases when the service can be redeployed?
> > > Affinity,
> > > > > > > failure,
> > > > > > > > > etc., right. It would be good to list all the cases on the
> > wiki
> > > > and
> > > > > > > then
> > > > > > > > > our tech writers will get everything documented.
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Denis,
> > > > > > > > > >
> > > > > > > > > > Services reassignment process takes into account previous
> > > > assignments
> > > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > > So, in the described case, ServiceA won't be moved from
> > node1
> > > > to
> > > > > > > node2.
> > > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > > dmagda@apache.org>
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Vyacheslav,
> > > > > > > > > > >
> > > > > > > > > > > First of all, thanks for archiving this milestone and
> > > > rolling out
> > > > > > > these
> > > > > > > > > >
> > > > > > > > > > new
> > > > > > > > > > > capabilities.
> > > > > > > > > > >
> > > > > > > > > > > Speaking of the topology change events [1], does the new
> > > > > > > architecture
> > > > > > > > > >
> > > > > > > > > > avoid
> > > > > > > > > > > a running service redeployment when a new node joins? For
> > > > instance,
> > > > > > > > >
> > > > > > > > > let's
> > > > > > > > > > > say I have ServiceA running node1, then node2 joins and I
> > > > don't
> > > > > > > want
> > > > > > > > >
> > > > > > > > > the
> > > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > >
> > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > > >
> > > > > > > > > > > > Thank you!
> > > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi I think wiki is better than any attached docs.
> > Could
> > > > you
> > > > > > > please
> > > > > > > > > > > >
> > > > > > > > > > > > create a
> > > > > > > > > > > > > page?
> > > > > > > > > > > > >
> > > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > > daradurvs@gmail.com
> > > > > > > > > >
> > > > > > > > > > :
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I prepared a description of the implemented
> > solution
> > > > and
> > > > > > > attached
> > > > > > > > > >
> > > > > > > > > > it
> > > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > This should help during a review. Should I post the
> > > > document
> > > > > > > into
> > > > > > > > > >
> > > > > > > > > > wiki
> > > > > > > > > > > > or
> > > > > > > > > > > > > > IEP?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> > solution
> > > > [1] [2],
> > > > > > > > > >
> > > > > > > > > > please?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > > Available now.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > However, we need additional review from other
> > > Ignite
> > > > > > > experts.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1]
> > > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> > Mekhanikov <
> > > > > > > > > > > >
> > > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does it make sense for .Net to specify service
> > > > class name
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > of
> > > > > > > > > > > > > > its
> > > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur
> > <
> > > > > > > > > > > >
> > > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think that the replacement of serialized
> > > > instance
> > > > > > > makes
> > > > > > > > > >
> > > > > > > > > > sense
> > > > > > > > > > > > to me
> > > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > > Setrakyan <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > > > Amelchev <
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I am working on task [1] that would
> > replace
> > > > > > > serialized
> > > > > > > > > > > >
> > > > > > > > > > > > service's
> > > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > > by service's class name and properties
> > map
> > > in
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > > > > > properties}
> > > > > > > > > >
> > > > > > > > > > instead
> > > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > > questions:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > > I suggest to mark them as deprecated and
> > > use
> > > > class
> > > > > > > name
> > > > > > > > > >
> > > > > > > > > > of
> > > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > > > parameters:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I think this makes sense, but I would like
> > > > other
> > > > > > > > > >
> > > > > > > > > > committers to
> > > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment
> > here.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > > > parameter
> > > > > > > > > >
> > > > > > > > > > mandatory
> > > > > > > > > > > > when
> > > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > > Is it make sense to add deploying methods
> > > > without
> > > > > > > it?
> > > > > > > > >
> > > > > > > > > For
> > > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > > >
> > > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > > Object> prop)
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I would always ask the user to pass the
> > > > property
> > > > > > > map, but
> > > > > > > > > >
> > > > > > > > > > would
> > > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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.
> > > >
> > >
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Vladimir.

What is correct term?


ср, 21 нояб. 2018 г., 10:29 Vladimir Ozerov vozerov@gridgain.com:

> Agree. Service deployment has nothing to do with PME. We should not use the
> same term for different things.
>
> вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:
>
> > Vyacheslav,
> >
> > I'm in process of reviewing your changes. Sorry for taking so long.
> > I posted the first portion of review comments yesterday.
> > I'd like to finish looking through the code. I'll post more comments
> later.
> >
> > I see, that you called things analogously to partition map exchange.
> > I realize, that there is an analogy in used procedures, but I don't
> really
> > like the idea to use the same names for everything.
> > The partition map exchange is called this way because it involves an
> actual
> > exchange of information.
> > All nodes need to tell each other, which partitions they have, and what
> > their states are.
> >
> > There is no exchange in case of service deployment, so I would skip the
> > "exchange" part.
> > And *single message ->* *full message* look more like *request ->
> response*
> > in case of services.
> >
> > Suppose we abandon the PME procedure and move to something else.
> > Then *ServiceDeploymentExchange* name won't make sense.
> > And I don't want to be in a situation, when I say to my colleague a word
> > "exchange",
> > and get "which one?" in return.
> > So, I'm for the meaningful names rather than analogous to something else.
> >
> > What do you think?
> >
> > Denis
> >
> > вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <da...@gmail.com>:
> >
> > > Denis, Yakov have you had a chance to review the solution?
> > >
> > > Igniters, we need to define a list of reviewers, otherwise no end in
> > sign.
> > >
> > > I'm ready to continue work on the Service Grid, including new features
> > > like hot-redeployment and versioning, also, I have ideas about new
> > > tools for monitoring and management which will be useful for our
> > > end-users.
> > >
> > > But for continuing work we need to overcome this first phase.
> > >
> > > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > > >
> > > > Denis, Yakov, feel free to contact me directly in case of questions.
> > > Thanks!
> > > >
> > > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> > dmekhanikov@gmail.com>
> > > wrote:
> > > > >
> > > > > Guys,
> > > > >
> > > > > I'd like to take a look at the changes before they are merged.
> > > > > I'll do my best to finish the review before the end of the upcoming
> > > week.
> > > > >
> > > > > Thanks!
> > > > > Denis
> > > > >
> > > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <nizhikov@apache.org
> >:
> > > > >
> > > > > > Hello, Vladimir.
> > > > > >
> > > > > > I'm agree with you.
> > > > > >
> > > > > > Can we write the list of reviewers for this feature?
> > > > > > Without a date or similar.
> > > > > > Just a list of experts who should review this feature.
> > > > > >
> > > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > > Igniters,
> > > > > > >
> > > > > > > This is very huge thing with complex algorithms behind. We
> should
> > > not
> > > > > > merge
> > > > > > > it to the product unless several additional thorough reviews
> are
> > > ready,
> > > > > > > irrespectively of how long will it take. We are about quality,
> > not
> > > speed.
> > > > > > >
> > > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > > > > >
> > > > > > > > Vyacheslav,
> > > > > > > >
> > > > > > > > What are the cases when the service can be redeployed?
> > Affinity,
> > > > > > failure,
> > > > > > > > etc., right. It would be good to list all the cases on the
> wiki
> > > and
> > > > > > then
> > > > > > > > our tech writers will get everything documented.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Denis,
> > > > > > > > >
> > > > > > > > > Services reassignment process takes into account previous
> > > assignments
> > > > > > > > > to avoid redundant redeployments.
> > > > > > > > > So, in the described case, ServiceA won't be moved from
> node1
> > > to
> > > > > > node2.
> > > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> > dmagda@apache.org>
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Vyacheslav,
> > > > > > > > > >
> > > > > > > > > > First of all, thanks for archiving this milestone and
> > > rolling out
> > > > > > these
> > > > > > > > >
> > > > > > > > > new
> > > > > > > > > > capabilities.
> > > > > > > > > >
> > > > > > > > > > Speaking of the topology change events [1], does the new
> > > > > > architecture
> > > > > > > > >
> > > > > > > > > avoid
> > > > > > > > > > a running service redeployment when a new node joins? For
> > > instance,
> > > > > > > >
> > > > > > > > let's
> > > > > > > > > > say I have ServiceA running node1, then node2 joins and I
> > > don't
> > > > > > want
> > > > > > > >
> > > > > > > > the
> > > > > > > > > > service to be redeployed to any other node.
> > > > > > > > > >
> > > > > > > > > > [1]
> > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > > >
> > > > > > > > > > > Thank you!
> > > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > > dpavlov.spb@gmail.com
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi I think wiki is better than any attached docs.
> Could
> > > you
> > > > > > please
> > > > > > > > > > >
> > > > > > > > > > > create a
> > > > > > > > > > > > page?
> > > > > > > > > > > >
> > > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > > daradurvs@gmail.com
> > > > > > > > >
> > > > > > > > > :
> > > > > > > > > > > >
> > > > > > > > > > > > > I prepared a description of the implemented
> solution
> > > and
> > > > > > attached
> > > > > > > > >
> > > > > > > > > it
> > > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > > >
> > > > > > > > > > > > > This should help during a review. Should I post the
> > > document
> > > > > > into
> > > > > > > > >
> > > > > > > > > wiki
> > > > > > > > > > > or
> > > > > > > > > > > > > IEP?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'd like to ask Ignite's experts review the
> solution
> > > [1] [2],
> > > > > > > > >
> > > > > > > > > please?
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur
> <
> > > > > > > > > > >
> > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > > Available now.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > However, we need additional review from other
> > Ignite
> > > > > > experts.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > [1]
> > > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis
> Mekhanikov <
> > > > > > > > > > >
> > > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does it make sense for .Net to specify service
> > > class name
> > > > > > > > >
> > > > > > > > > instead
> > > > > > > > > > > of
> > > > > > > > > > > > > its
> > > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur
> <
> > > > > > > > > > >
> > > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think that the replacement of serialized
> > > instance
> > > > > > makes
> > > > > > > > >
> > > > > > > > > sense
> > > > > > > > > > > to me
> > > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > > Setrakyan <
> > > > > > > > > > > > >
> > > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > > Amelchev <
> > > > > > > > > > > > >
> > > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I am working on task [1] that would
> replace
> > > > > > serialized
> > > > > > > > > > >
> > > > > > > > > > > service's
> > > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > > by service's class name and properties
> map
> > in
> > > > > > > > > > > > >
> > > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > > > > properties}
> > > > > > > > >
> > > > > > > > > instead
> > > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'd like to clarify the following
> > questions:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > > I suggest to mark them as deprecated and
> > use
> > > class
> > > > > > name
> > > > > > > > >
> > > > > > > > > of
> > > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > > parameters:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > >
> > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > >
> > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > Object> prop)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I think this makes sense, but I would like
> > > other
> > > > > > > > >
> > > > > > > > > committers to
> > > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment
> here.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > > parameter
> > > > > > > > >
> > > > > > > > > mandatory
> > > > > > > > > > > when
> > > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > > Is it make sense to add deploying methods
> > > without
> > > > > > it?
> > > > > > > >
> > > > > > > > For
> > > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > >
> > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > > >
> > > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > > Object> prop)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I would always ask the user to pass the
> > > property
> > > > > > map, but
> > > > > > > > >
> > > > > > > > > would
> > > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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.
> > >
> >
>

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
Agree. Service deployment has nothing to do with PME. We should not use the
same term for different things.

вт, 20 нояб. 2018 г. в 17:19, Denis Mekhanikov <dm...@gmail.com>:

> Vyacheslav,
>
> I'm in process of reviewing your changes. Sorry for taking so long.
> I posted the first portion of review comments yesterday.
> I'd like to finish looking through the code. I'll post more comments later.
>
> I see, that you called things analogously to partition map exchange.
> I realize, that there is an analogy in used procedures, but I don't really
> like the idea to use the same names for everything.
> The partition map exchange is called this way because it involves an actual
> exchange of information.
> All nodes need to tell each other, which partitions they have, and what
> their states are.
>
> There is no exchange in case of service deployment, so I would skip the
> "exchange" part.
> And *single message ->* *full message* look more like *request -> response*
> in case of services.
>
> Suppose we abandon the PME procedure and move to something else.
> Then *ServiceDeploymentExchange* name won't make sense.
> And I don't want to be in a situation, when I say to my colleague a word
> "exchange",
> and get "which one?" in return.
> So, I'm for the meaningful names rather than analogous to something else.
>
> What do you think?
>
> Denis
>
> вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <da...@gmail.com>:
>
> > Denis, Yakov have you had a chance to review the solution?
> >
> > Igniters, we need to define a list of reviewers, otherwise no end in
> sign.
> >
> > I'm ready to continue work on the Service Grid, including new features
> > like hot-redeployment and versioning, also, I have ideas about new
> > tools for monitoring and management which will be useful for our
> > end-users.
> >
> > But for continuing work we need to overcome this first phase.
> >
> > On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > >
> > > Denis, Yakov, feel free to contact me directly in case of questions.
> > Thanks!
> > >
> > > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > wrote:
> > > >
> > > > Guys,
> > > >
> > > > I'd like to take a look at the changes before they are merged.
> > > > I'll do my best to finish the review before the end of the upcoming
> > week.
> > > >
> > > > Thanks!
> > > > Denis
> > > >
> > > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:
> > > >
> > > > > Hello, Vladimir.
> > > > >
> > > > > I'm agree with you.
> > > > >
> > > > > Can we write the list of reviewers for this feature?
> > > > > Without a date or similar.
> > > > > Just a list of experts who should review this feature.
> > > > >
> > > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > > Igniters,
> > > > > >
> > > > > > This is very huge thing with complex algorithms behind. We should
> > not
> > > > > merge
> > > > > > it to the product unless several additional thorough reviews are
> > ready,
> > > > > > irrespectively of how long will it take. We are about quality,
> not
> > speed.
> > > > > >
> > > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > What are the cases when the service can be redeployed?
> Affinity,
> > > > > failure,
> > > > > > > etc., right. It would be good to list all the cases on the wiki
> > and
> > > > > then
> > > > > > > our tech writers will get everything documented.
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Services reassignment process takes into account previous
> > assignments
> > > > > > > > to avoid redundant redeployments.
> > > > > > > > So, in the described case, ServiceA won't be moved from node1
> > to
> > > > > node2.
> > > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <
> dmagda@apache.org>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Vyacheslav,
> > > > > > > > >
> > > > > > > > > First of all, thanks for archiving this milestone and
> > rolling out
> > > > > these
> > > > > > > >
> > > > > > > > new
> > > > > > > > > capabilities.
> > > > > > > > >
> > > > > > > > > Speaking of the topology change events [1], does the new
> > > > > architecture
> > > > > > > >
> > > > > > > > avoid
> > > > > > > > > a running service redeployment when a new node joins? For
> > instance,
> > > > > > >
> > > > > > > let's
> > > > > > > > > say I have ServiceA running node1, then node2 joins and I
> > don't
> > > > > want
> > > > > > >
> > > > > > > the
> > > > > > > > > service to be redeployed to any other node.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > > daradurvs@gmail.com
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > > >
> > > > > > > > > > Thank you!
> > > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > > dpavlov.spb@gmail.com
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi I think wiki is better than any attached docs. Could
> > you
> > > > > please
> > > > > > > > > >
> > > > > > > > > > create a
> > > > > > > > > > > page?
> > > > > > > > > > >
> > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > daradurvs@gmail.com
> > > > > > > >
> > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > I prepared a description of the implemented solution
> > and
> > > > > attached
> > > > > > > >
> > > > > > > > it
> > > > > > > > > > > > to the issue [1].
> > > > > > > > > > > >
> > > > > > > > > > > > This should help during a review. Should I post the
> > document
> > > > > into
> > > > > > > >
> > > > > > > > wiki
> > > > > > > > > > or
> > > > > > > > > > > > IEP?
> > > > > > > > > > > >
> > > > > > > > > > > > I'd like to ask Ignite's experts review the solution
> > [1] [2],
> > > > > > > >
> > > > > > > > please?
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > > > > > >
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > > >
> > > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> > Available now.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > > >
> > > > > > > > > > > > > However, we need additional review from other
> Ignite
> > > > > experts.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > > >
> > > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > > >
> > > > > > > > > > > > > [1]
> > https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > > > > > >
> > > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Does it make sense for .Net to specify service
> > class name
> > > > > > > >
> > > > > > > > instead
> > > > > > > > > > of
> > > > > > > > > > > > its
> > > > > > > > > > > > > > implementation?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Denis
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > > > > > >
> > > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think that the replacement of serialized
> > instance
> > > > > makes
> > > > > > > >
> > > > > > > > sense
> > > > > > > > > > to me
> > > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> > Setrakyan <
> > > > > > > > > > > >
> > > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > Amelchev <
> > > > > > > > > > > >
> > > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I am working on task [1] that would replace
> > > > > serialized
> > > > > > > > > >
> > > > > > > > > > service's
> > > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > > by service's class name and properties map
> in
> > > > > > > > > > > >
> > > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > > > properties}
> > > > > > > >
> > > > > > > > instead
> > > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > I'd like to clarify the following
> questions:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > > I suggest to mark them as deprecated and
> use
> > class
> > > > > name
> > > > > > > >
> > > > > > > > of
> > > > > > > > > > > > provided
> > > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > > Also to add deploying methods with new
> > parameters:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > Object> prop)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I think this makes sense, but I would like
> > other
> > > > > > > >
> > > > > > > > committers to
> > > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> > parameter
> > > > > > > >
> > > > > > > > mandatory
> > > > > > > > > > when
> > > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > > Is it make sense to add deploying methods
> > without
> > > > > it?
> > > > > > >
> > > > > > > For
> > > > > > > > > > > > example:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > > >
> > > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> > Object> prop)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I would always ask the user to pass the
> > property
> > > > > map, but
> > > > > > > >
> > > > > > > > would
> > > > > > > > > > > > allow it
> > > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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.
> >
>

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Vyacheslav,

I'm in process of reviewing your changes. Sorry for taking so long.
I posted the first portion of review comments yesterday.
I'd like to finish looking through the code. I'll post more comments later.

I see, that you called things analogously to partition map exchange.
I realize, that there is an analogy in used procedures, but I don't really
like the idea to use the same names for everything.
The partition map exchange is called this way because it involves an actual
exchange of information.
All nodes need to tell each other, which partitions they have, and what
their states are.

There is no exchange in case of service deployment, so I would skip the
"exchange" part.
And *single message ->* *full message* look more like *request -> response*
in case of services.

Suppose we abandon the PME procedure and move to something else.
Then *ServiceDeploymentExchange* name won't make sense.
And I don't want to be in a situation, when I say to my colleague a word
"exchange",
and get "which one?" in return.
So, I'm for the meaningful names rather than analogous to something else.

What do you think?

Denis

вт, 20 нояб. 2018 г. в 12:09, Vyacheslav Daradur <da...@gmail.com>:

> Denis, Yakov have you had a chance to review the solution?
>
> Igniters, we need to define a list of reviewers, otherwise no end in sign.
>
> I'm ready to continue work on the Service Grid, including new features
> like hot-redeployment and versioning, also, I have ideas about new
> tools for monitoring and management which will be useful for our
> end-users.
>
> But for continuing work we need to overcome this first phase.
>
> On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
> >
> > Denis, Yakov, feel free to contact me directly in case of questions.
> Thanks!
> >
> > On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <dm...@gmail.com>
> wrote:
> > >
> > > Guys,
> > >
> > > I'd like to take a look at the changes before they are merged.
> > > I'll do my best to finish the review before the end of the upcoming
> week.
> > >
> > > Thanks!
> > > Denis
> > >
> > > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > > Hello, Vladimir.
> > > >
> > > > I'm agree with you.
> > > >
> > > > Can we write the list of reviewers for this feature?
> > > > Without a date or similar.
> > > > Just a list of experts who should review this feature.
> > > >
> > > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > > Igniters,
> > > > >
> > > > > This is very huge thing with complex algorithms behind. We should
> not
> > > > merge
> > > > > it to the product unless several additional thorough reviews are
> ready,
> > > > > irrespectively of how long will it take. We are about quality, not
> speed.
> > > > >
> > > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > What are the cases when the service can be redeployed? Affinity,
> > > > failure,
> > > > > > etc., right. It would be good to list all the cases on the wiki
> and
> > > > then
> > > > > > our tech writers will get everything documented.
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > > daradurvs@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Denis,
> > > > > > >
> > > > > > > Services reassignment process takes into account previous
> assignments
> > > > > > > to avoid redundant redeployments.
> > > > > > > So, in the described case, ServiceA won't be moved from node1
> to
> > > > node2.
> > > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org>
> > > > wrote:
> > > > > > > >
> > > > > > > > Vyacheslav,
> > > > > > > >
> > > > > > > > First of all, thanks for archiving this milestone and
> rolling out
> > > > these
> > > > > > >
> > > > > > > new
> > > > > > > > capabilities.
> > > > > > > >
> > > > > > > > Speaking of the topology change events [1], does the new
> > > > architecture
> > > > > > >
> > > > > > > avoid
> > > > > > > > a running service redeployment when a new node joins? For
> instance,
> > > > > >
> > > > > > let's
> > > > > > > > say I have ServiceA running node1, then node2 joins and I
> don't
> > > > want
> > > > > >
> > > > > > the
> > > > > > > > service to be redeployed to any other node.
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > >
> > > > > >
> > > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > > >
> > > > > > > > --
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > > daradurvs@gmail.com
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > > >
> > > > > >
> > > > > >
> > > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > > >
> > > > > > > > > Thank you!
> > > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > > dpavlov.spb@gmail.com
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi I think wiki is better than any attached docs. Could
> you
> > > > please
> > > > > > > > >
> > > > > > > > > create a
> > > > > > > > > > page?
> > > > > > > > > >
> > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > daradurvs@gmail.com
> > > > > > >
> > > > > > > :
> > > > > > > > > >
> > > > > > > > > > > I prepared a description of the implemented solution
> and
> > > > attached
> > > > > > >
> > > > > > > it
> > > > > > > > > > > to the issue [1].
> > > > > > > > > > >
> > > > > > > > > > > This should help during a review. Should I post the
> document
> > > > into
> > > > > > >
> > > > > > > wiki
> > > > > > > > > or
> > > > > > > > > > > IEP?
> > > > > > > > > > >
> > > > > > > > > > > I'd like to ask Ignite's experts review the solution
> [1] [2],
> > > > > > >
> > > > > > > please?
> > > > > > > > > > >
> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > > > > >
> > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > > >
> > > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch
> Available now.
> > > > > > > > > > > >
> > > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > > >
> > > > > > > > > > > > However, we need additional review from other Ignite
> > > > experts.
> > > > > > > > > > > >
> > > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > > >
> > > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > > >
> > > > > > > > > > > > [1]
> https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > > > > >
> > > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Does it make sense for .Net to specify service
> class name
> > > > > > >
> > > > > > > instead
> > > > > > > > > of
> > > > > > > > > > > its
> > > > > > > > > > > > > implementation?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Denis
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > > > > >
> > > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I think that the replacement of serialized
> instance
> > > > makes
> > > > > > >
> > > > > > > sense
> > > > > > > > > to me
> > > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy
> Setrakyan <
> > > > > > > > > > >
> > > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> Amelchev <
> > > > > > > > > > >
> > > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I am working on task [1] that would replace
> > > > serialized
> > > > > > > > >
> > > > > > > > > service's
> > > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > > by service's class name and properties map in
> > > > > > > > > > >
> > > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > > properties}
> > > > > > >
> > > > > > > instead
> > > > > > > > > > > {Service
> > > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > > I suggest to mark them as deprecated and use
> class
> > > > name
> > > > > > >
> > > > > > > of
> > > > > > > > > > > provided
> > > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > > Also to add deploying methods with new
> parameters:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > >
> > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > >
> > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> Object> prop)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I think this makes sense, but I would like
> other
> > > > > > >
> > > > > > > committers to
> > > > > > > > > > > confirm.
> > > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties}
> parameter
> > > > > > >
> > > > > > > mandatory
> > > > > > > > > when
> > > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > > Is it make sense to add deploying methods
> without
> > > > it?
> > > > > >
> > > > > > For
> > > > > > > > > > > example:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > >
> > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > > >
> > > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > > prj,
> > > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > > name, String srvcClsName, Map<String,
> Object> prop)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I would always ask the user to pass the
> property
> > > > map, but
> > > > > > >
> > > > > > > would
> > > > > > > > > > > allow it
> > > > > > > > > > > > > > to
> > > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis, Yakov have you had a chance to review the solution?

Igniters, we need to define a list of reviewers, otherwise no end in sign.

I'm ready to continue work on the Service Grid, including new features
like hot-redeployment and versioning, also, I have ideas about new
tools for monitoring and management which will be useful for our
end-users.

But for continuing work we need to overcome this first phase.

On Tue, Nov 13, 2018 at 1:09 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Denis, Yakov, feel free to contact me directly in case of questions. Thanks!
>
> On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <dm...@gmail.com> wrote:
> >
> > Guys,
> >
> > I'd like to take a look at the changes before they are merged.
> > I'll do my best to finish the review before the end of the upcoming week.
> >
> > Thanks!
> > Denis
> >
> > сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:
> >
> > > Hello, Vladimir.
> > >
> > > I'm agree with you.
> > >
> > > Can we write the list of reviewers for this feature?
> > > Without a date or similar.
> > > Just a list of experts who should review this feature.
> > >
> > > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > > Igniters,
> > > >
> > > > This is very huge thing with complex algorithms behind. We should not
> > > merge
> > > > it to the product unless several additional thorough reviews are ready,
> > > > irrespectively of how long will it take. We are about quality, not speed.
> > > >
> > > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > > >
> > > > > Vyacheslav,
> > > > >
> > > > > What are the cases when the service can be redeployed? Affinity,
> > > failure,
> > > > > etc., right. It would be good to list all the cases on the wiki and
> > > then
> > > > > our tech writers will get everything documented.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > > daradurvs@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Denis,
> > > > > >
> > > > > > Services reassignment process takes into account previous assignments
> > > > > > to avoid redundant redeployments.
> > > > > > So, in the described case, ServiceA won't be moved from node1 to
> > > node2.
> > > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org>
> > > wrote:
> > > > > > >
> > > > > > > Vyacheslav,
> > > > > > >
> > > > > > > First of all, thanks for archiving this milestone and rolling out
> > > these
> > > > > >
> > > > > > new
> > > > > > > capabilities.
> > > > > > >
> > > > > > > Speaking of the topology change events [1], does the new
> > > architecture
> > > > > >
> > > > > > avoid
> > > > > > > a running service redeployment when a new node joins? For instance,
> > > > >
> > > > > let's
> > > > > > > say I have ServiceA running node1, then node2 joins and I don't
> > > want
> > > > >
> > > > > the
> > > > > > > service to be redeployed to any other node.
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > >
> > > > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > > daradurvs@gmail.com
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > > >
> > > > >
> > > > >
> > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > > >
> > > > > > > > Thank you!
> > > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > > dpavlov.spb@gmail.com
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi I think wiki is better than any attached docs. Could you
> > > please
> > > > > > > >
> > > > > > > > create a
> > > > > > > > > page?
> > > > > > > > >
> > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > daradurvs@gmail.com
> > > > > >
> > > > > > :
> > > > > > > > >
> > > > > > > > > > I prepared a description of the implemented solution and
> > > attached
> > > > > >
> > > > > > it
> > > > > > > > > > to the issue [1].
> > > > > > > > > >
> > > > > > > > > > This should help during a review. Should I post the document
> > > into
> > > > > >
> > > > > > wiki
> > > > > > > > or
> > > > > > > > > > IEP?
> > > > > > > > > >
> > > > > > > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> > > > > >
> > > > > > please?
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > > > >
> > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > > >
> > > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > > > > > > >
> > > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > > >
> > > > > > > > > > > However, we need additional review from other Ignite
> > > experts.
> > > > > > > > > > >
> > > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > > >
> > > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > > >
> > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > > > >
> > > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > > >
> > > > > > > > > > > > Does it make sense for .Net to specify service class name
> > > > > >
> > > > > > instead
> > > > > > > > of
> > > > > > > > > > its
> > > > > > > > > > > > implementation?
> > > > > > > > > > > >
> > > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > > >
> > > > > > > > > > > > Denis
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > > > >
> > > > > > > > daradurvs@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > I think that the replacement of serialized instance
> > > makes
> > > > > >
> > > > > > sense
> > > > > > > > to me
> > > > > > > > > > > > > for Java part.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > > > > > >
> > > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > > > >
> > > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I am working on task [1] that would replace
> > > serialized
> > > > > > > >
> > > > > > > > service's
> > > > > > > > > > > > > instance
> > > > > > > > > > > > > > > by service's class name and properties map in
> > > > > > > > > >
> > > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > > properties}
> > > > > >
> > > > > > instead
> > > > > > > > > > {Service
> > > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > > I suggest to mark them as deprecated and use class
> > > name
> > > > > >
> > > > > > of
> > > > > > > > > > provided
> > > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > >
> > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > prj,
> > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > >
> > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > prj,
> > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I think this makes sense, but I would like other
> > > > > >
> > > > > > committers to
> > > > > > > > > > confirm.
> > > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> > > > > >
> > > > > > mandatory
> > > > > > > > when
> > > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > > Is it make sense to add deploying methods without
> > > it?
> > > > >
> > > > > For
> > > > > > > > > > example:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > >
> > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > prj,
> > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > > >
> > > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > > prj,
> > > > > > > > > > > > > > > String
> > > > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I would always ask the user to pass the property
> > > map, but
> > > > > >
> > > > > > would
> > > > > > > > > > allow it
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > be null.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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.

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis, Yakov, feel free to contact me directly in case of questions. Thanks!

On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <dm...@gmail.com> wrote:
>
> Guys,
>
> I'd like to take a look at the changes before they are merged.
> I'll do my best to finish the review before the end of the upcoming week.
>
> Thanks!
> Denis
>
> сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:
>
> > Hello, Vladimir.
> >
> > I'm agree with you.
> >
> > Can we write the list of reviewers for this feature?
> > Without a date or similar.
> > Just a list of experts who should review this feature.
> >
> > В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > > Igniters,
> > >
> > > This is very huge thing with complex algorithms behind. We should not
> > merge
> > > it to the product unless several additional thorough reviews are ready,
> > > irrespectively of how long will it take. We are about quality, not speed.
> > >
> > > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> > >
> > > > Vyacheslav,
> > > >
> > > > What are the cases when the service can be redeployed? Affinity,
> > failure,
> > > > etc., right. It would be good to list all the cases on the wiki and
> > then
> > > > our tech writers will get everything documented.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > >
> > > > > Denis,
> > > > >
> > > > > Services reassignment process takes into account previous assignments
> > > > > to avoid redundant redeployments.
> > > > > So, in the described case, ServiceA won't be moved from node1 to
> > node2.
> > > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org>
> > wrote:
> > > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > First of all, thanks for archiving this milestone and rolling out
> > these
> > > > >
> > > > > new
> > > > > > capabilities.
> > > > > >
> > > > > > Speaking of the topology change events [1], does the new
> > architecture
> > > > >
> > > > > avoid
> > > > > > a running service redeployment when a new node joins? For instance,
> > > >
> > > > let's
> > > > > > say I have ServiceA running node1, then node2 joins and I don't
> > want
> > > >
> > > > the
> > > > > > service to be redeployed to any other node.
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > > > > wrote:
> > > > > >
> > > > > > > Dmitriy, I published documentation in wiki:
> > > > > > >
> > > >
> > > >
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > > >
> > > > > > > Thank you!
> > > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> > dpavlov.spb@gmail.com
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi I think wiki is better than any attached docs. Could you
> > please
> > > > > > >
> > > > > > > create a
> > > > > > > > page?
> > > > > > > >
> > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > daradurvs@gmail.com
> > > > >
> > > > > :
> > > > > > > >
> > > > > > > > > I prepared a description of the implemented solution and
> > attached
> > > > >
> > > > > it
> > > > > > > > > to the issue [1].
> > > > > > > > >
> > > > > > > > > This should help during a review. Should I post the document
> > into
> > > > >
> > > > > wiki
> > > > > > > or
> > > > > > > > > IEP?
> > > > > > > > >
> > > > > > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> > > > >
> > > > > please?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > > >
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > > >
> > > > > > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > > > > > >
> > > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > > >
> > > > > > > > > > However, we need additional review from other Ignite
> > experts.
> > > > > > > > > >
> > > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > > >
> > > > > > > > > > Could someone step in and do the review?
> > > > > > > > > >
> > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > > >
> > > > > > > dmekhanikov@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Pavel, could you assist?
> > > > > > > > > > >
> > > > > > > > > > > Does it make sense for .Net to specify service class name
> > > > >
> > > > > instead
> > > > > > > of
> > > > > > > > > its
> > > > > > > > > > > implementation?
> > > > > > > > > > >
> > > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > > >
> > > > > > > > > > > Denis
> > > > > > > > > > >
> > > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > > >
> > > > > > > daradurvs@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I think that the replacement of serialized instance
> > makes
> > > > >
> > > > > sense
> > > > > > > to me
> > > > > > > > > > > > for Java part.
> > > > > > > > > > > >
> > > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > > > > >
> > > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > > >
> > > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I am working on task [1] that would replace
> > serialized
> > > > > > >
> > > > > > > service's
> > > > > > > > > > > > instance
> > > > > > > > > > > > > > by service's class name and properties map in
> > > > > > > > >
> > > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > > {String className} + {Map<String, Object>
> > properties}
> > > > >
> > > > > instead
> > > > > > > > > {Service
> > > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > > I suggest to mark them as deprecated and use class
> > name
> > > > >
> > > > > of
> > > > > > > > > provided
> > > > > > > > > > > > > > instance.
> > > > > > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > >
> > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > prj,
> > > > > > > > > > > > > > String
> > > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > >
> > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > prj,
> > > > > > > > > > > > > > String
> > > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I think this makes sense, but I would like other
> > > > >
> > > > > committers to
> > > > > > > > > confirm.
> > > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> > > > >
> > > > > mandatory
> > > > > > > when
> > > > > > > > > > > > deploying a
> > > > > > > > > > > > > > service?
> > > > > > > > > > > > > > Is it make sense to add deploying methods without
> > it?
> > > >
> > > > For
> > > > > > > > > example:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > >
> > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > prj,
> > > > > > > > > > > > > > String
> > > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > > >
> > > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > > prj,
> > > > > > > > > > > > > > String
> > > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I would always ask the user to pass the property
> > map, but
> > > > >
> > > > > would
> > > > > > > > > allow it
> > > > > > > > > > > > to
> > > > > > > > > > > > > be null.
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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.

Re: Service grid redesign

Posted by Denis Mekhanikov <dm...@gmail.com>.
Guys,

I'd like to take a look at the changes before they are merged.
I'll do my best to finish the review before the end of the upcoming week.

Thanks!
Denis

сб, 10 нояб. 2018 г. в 14:25, Nikolay Izhikov <ni...@apache.org>:

> Hello, Vladimir.
>
> I'm agree with you.
>
> Can we write the list of reviewers for this feature?
> Without a date or similar.
> Just a list of experts who should review this feature.
>
> В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> > Igniters,
> >
> > This is very huge thing with complex algorithms behind. We should not
> merge
> > it to the product unless several additional thorough reviews are ready,
> > irrespectively of how long will it take. We are about quality, not speed.
> >
> > сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> >
> > > Vyacheslav,
> > >
> > > What are the cases when the service can be redeployed? Affinity,
> failure,
> > > etc., right. It would be good to list all the cases on the wiki and
> then
> > > our tech writers will get everything documented.
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > >
> > > > Denis,
> > > >
> > > > Services reassignment process takes into account previous assignments
> > > > to avoid redundant redeployments.
> > > > So, in the described case, ServiceA won't be moved from node1 to
> node2.
> > > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org>
> wrote:
> > > > >
> > > > > Vyacheslav,
> > > > >
> > > > > First of all, thanks for archiving this milestone and rolling out
> these
> > > >
> > > > new
> > > > > capabilities.
> > > > >
> > > > > Speaking of the topology change events [1], does the new
> architecture
> > > >
> > > > avoid
> > > > > a running service redeployment when a new node joins? For instance,
> > >
> > > let's
> > > > > say I have ServiceA running node1, then node2 joins and I don't
> want
> > >
> > > the
> > > > > service to be redeployed to any other node.
> > > > >
> > > > > [1]
> > > > >
> > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <
> daradurvs@gmail.com
> > > > > wrote:
> > > > >
> > > > > > Dmitriy, I published documentation in wiki:
> > > > > >
> > >
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > >
> > > > > > Thank you!
> > > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <
> dpavlov.spb@gmail.com
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi I think wiki is better than any attached docs. Could you
> please
> > > > > >
> > > > > > create a
> > > > > > > page?
> > > > > > >
> > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> daradurvs@gmail.com
> > > >
> > > > :
> > > > > > >
> > > > > > > > I prepared a description of the implemented solution and
> attached
> > > >
> > > > it
> > > > > > > > to the issue [1].
> > > > > > > >
> > > > > > > > This should help during a review. Should I post the document
> into
> > > >
> > > > wiki
> > > > > > or
> > > > > > > > IEP?
> > > > > > > >
> > > > > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> > > >
> > > > please?
> > > > > > > >
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > >
> > > > > > daradurvs@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi, Igniters! Good news!
> > > > > > > > >
> > > > > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > > > > >
> > > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > >
> > > > > > > > > However, we need additional review from other Ignite
> experts.
> > > > > > > > >
> > > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > >
> > > > > > > > > Could someone step in and do the review?
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > >
> > > > > > dmekhanikov@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Pavel, could you assist?
> > > > > > > > > >
> > > > > > > > > > Does it make sense for .Net to specify service class name
> > > >
> > > > instead
> > > > > > of
> > > > > > > > its
> > > > > > > > > > implementation?
> > > > > > > > > >
> > > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > >
> > > > > > daradurvs@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I think that the replacement of serialized instance
> makes
> > > >
> > > > sense
> > > > > > to me
> > > > > > > > > > > for Java part.
> > > > > > > > > > >
> > > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > > > >
> > > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > >
> > > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I am working on task [1] that would replace
> serialized
> > > > > >
> > > > > > service's
> > > > > > > > > > > instance
> > > > > > > > > > > > > by service's class name and properties map in
> > > > > > > >
> > > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > > {String className} + {Map<String, Object>
> properties}
> > > >
> > > > instead
> > > > > > > > {Service
> > > > > > > > > > > > > srvc}.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > >
> > > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > > I suggest to mark them as deprecated and use class
> name
> > > >
> > > > of
> > > > > > > > provided
> > > > > > > > > > > > > instance.
> > > > > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > > > > >
> > > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > >
> > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > prj,
> > > > > > > > > > > > > String
> > > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > >
> > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > >
> > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > prj,
> > > > > > > > > > > > > String
> > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I think this makes sense, but I would like other
> > > >
> > > > committers to
> > > > > > > > confirm.
> > > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> > > >
> > > > mandatory
> > > > > > when
> > > > > > > > > > > deploying a
> > > > > > > > > > > > > service?
> > > > > > > > > > > > > Is it make sense to add deploying methods without
> it?
> > >
> > > For
> > > > > > > > example:
> > > > > > > > > > > > >
> > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > >
> > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > prj,
> > > > > > > > > > > > > String
> > > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > >
> > > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > >
> > > > > > deployNodeSingleton(ClusterGroup
> > > > > > > > prj,
> > > > > > > > > > > > > String
> > > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I would always ask the user to pass the property
> map, but
> > > >
> > > > would
> > > > > > > > allow it
> > > > > > > > > > > to
> > > > > > > > > > > > be null.
> > > > > > > > > > > >
> > > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
>

Re: Service grid redesign

Posted by Nikolay Izhikov <ni...@apache.org>.
Hello, Vladimir.

I'm agree with you.

Can we write the list of reviewers for this feature?
Without a date or similar. 
Just a list of experts who should review this feature.

В Сб, 10/11/2018 в 14:01 +0300, Vladimir Ozerov пишет:
> Igniters,
> 
> This is very huge thing with complex algorithms behind. We should not merge
> it to the product unless several additional thorough reviews are ready,
> irrespectively of how long will it take. We are about quality, not speed.
> 
> сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:
> 
> > Vyacheslav,
> > 
> > What are the cases when the service can be redeployed? Affinity, failure,
> > etc., right. It would be good to list all the cases on the wiki and then
> > our tech writers will get everything documented.
> > 
> > --
> > Denis
> > 
> > On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > 
> > > Denis,
> > > 
> > > Services reassignment process takes into account previous assignments
> > > to avoid redundant redeployments.
> > > So, in the described case, ServiceA won't be moved from node1 to node2.
> > > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org> wrote:
> > > > 
> > > > Vyacheslav,
> > > > 
> > > > First of all, thanks for archiving this milestone and rolling out these
> > > 
> > > new
> > > > capabilities.
> > > > 
> > > > Speaking of the topology change events [1], does the new architecture
> > > 
> > > avoid
> > > > a running service redeployment when a new node joins? For instance,
> > 
> > let's
> > > > say I have ServiceA running node1, then node2 joins and I don't want
> > 
> > the
> > > > service to be redeployed to any other node.
> > > > 
> > > > [1]
> > > > 
> > 
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > > > 
> > > > --
> > > > Denis
> > > > 
> > > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <daradurvs@gmail.com
> > > > wrote:
> > > > 
> > > > > Dmitriy, I published documentation in wiki:
> > > > > 
> > 
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > > > 
> > > > > Thank you!
> > > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dpavlov.spb@gmail.com
> > > > > wrote:
> > > > > > 
> > > > > > Hi I think wiki is better than any attached docs. Could you please
> > > > > 
> > > > > create a
> > > > > > page?
> > > > > > 
> > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <daradurvs@gmail.com
> > > 
> > > :
> > > > > > 
> > > > > > > I prepared a description of the implemented solution and attached
> > > 
> > > it
> > > > > > > to the issue [1].
> > > > > > > 
> > > > > > > This should help during a review. Should I post the document into
> > > 
> > > wiki
> > > > > or
> > > > > > > IEP?
> > > > > > > 
> > > > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> > > 
> > > please?
> > > > > > > 
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > > 
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > Hi, Igniters! Good news!
> > > > > > > > 
> > > > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > > > > 
> > > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > > > 
> > > > > > > > However, we need additional review from other Ignite experts.
> > > > > > > > 
> > > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > > > 
> > > > > > > > Could someone step in and do the review?
> > > > > > > > 
> > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > > 
> > > > > dmekhanikov@gmail.com>
> > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > Pavel, could you assist?
> > > > > > > > > 
> > > > > > > > > Does it make sense for .Net to specify service class name
> > > 
> > > instead
> > > > > of
> > > > > > > its
> > > > > > > > > implementation?
> > > > > > > > > 
> > > > > > > > > I think, it shouldn't be a problem.
> > > > > > > > > 
> > > > > > > > > Denis
> > > > > > > > > 
> > > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > > 
> > > > > daradurvs@gmail.com>
> > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > I think that the replacement of serialized instance makes
> > > 
> > > sense
> > > > > to me
> > > > > > > > > > for Java part.
> > > > > > > > > > 
> > > > > > > > > > But how it should work for .NET client?
> > > > > > > > > > 
> > > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > > > 
> > > > > > > dsetrakyan@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > 
> > > > > > > nsamelchev@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > > > 
> > > > > > > > > > > > I am working on task [1] that would replace serialized
> > > > > 
> > > > > service's
> > > > > > > > > > instance
> > > > > > > > > > > > by service's class name and properties map in
> > > > > > > 
> > > > > > > {ServiceConfiguration}.
> > > > > > > > > > > > 
> > > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > > {String className} + {Map<String, Object> properties}
> > > 
> > > instead
> > > > > > > {Service
> > > > > > > > > > > > srvc}.
> > > > > > > > > > > > 
> > > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > > > 
> > > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > > I suggest to mark them as deprecated and use class name
> > > 
> > > of
> > > > > > > provided
> > > > > > > > > > > > instance.
> > > > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > > > > 
> > > > > > > > > > > > @Deprecated
> > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > 
> > > > > deployNodeSingleton(ClusterGroup
> > > > > > > prj,
> > > > > > > > > > > > String
> > > > > > > > > > > > name, Service svc)
> > > > > > > > > > > > 
> > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > 
> > > > > deployNodeSingleton(ClusterGroup
> > > > > > > prj,
> > > > > > > > > > > > String
> > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I think this makes sense, but I would like other
> > > 
> > > committers to
> > > > > > > confirm.
> > > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> > > 
> > > mandatory
> > > > > when
> > > > > > > > > > deploying a
> > > > > > > > > > > > service?
> > > > > > > > > > > > Is it make sense to add deploying methods without it?
> > 
> > For
> > > > > > > example:
> > > > > > > > > > > > 
> > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > 
> > > > > deployNodeSingleton(ClusterGroup
> > > > > > > prj,
> > > > > > > > > > > > String
> > > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > > > 
> > > > > > > > > > > > public IgniteInternalFuture<?>
> > > > > 
> > > > > deployNodeSingleton(ClusterGroup
> > > > > > > prj,
> > > > > > > > > > > > String
> > > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > I would always ask the user to pass the property map, but
> > > 
> > > would
> > > > > > > allow it
> > > > > > > > > > to
> > > > > > > > > > > be null.
> > > > > > > > > > > 
> > > > > > > > > > > D.
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > --
> > > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > > 
> > > 
> > > 
> > > 
> > > --
> > > Best Regards, Vyacheslav D.
> > >

Re: Service grid redesign

Posted by Vladimir Ozerov <vo...@gridgain.com>.
Igniters,

This is very huge thing with complex algorithms behind. We should not merge
it to the product unless several additional thorough reviews are ready,
irrespectively of how long will it take. We are about quality, not speed.

сб, 10 нояб. 2018 г. в 1:30, Denis Magda <dm...@apache.org>:

> Vyacheslav,
>
> What are the cases when the service can be redeployed? Affinity, failure,
> etc., right. It would be good to list all the cases on the wiki and then
> our tech writers will get everything documented.
>
> --
> Denis
>
> On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > Denis,
> >
> > Services reassignment process takes into account previous assignments
> > to avoid redundant redeployments.
> > So, in the described case, ServiceA won't be moved from node1 to node2.
> > On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org> wrote:
> > >
> > > Vyacheslav,
> > >
> > > First of all, thanks for archiving this milestone and rolling out these
> > new
> > > capabilities.
> > >
> > > Speaking of the topology change events [1], does the new architecture
> > avoid
> > > a running service redeployment when a new node joins? For instance,
> let's
> > > say I have ServiceA running node1, then node2 joins and I don't want
> the
> > > service to be redeployed to any other node.
> > >
> > > [1]
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> > >
> > > --
> > > Denis
> > >
> > > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <daradurvs@gmail.com
> >
> > > wrote:
> > >
> > > > Dmitriy, I published documentation in wiki:
> > > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > > >
> > > > Thank you!
> > > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dpavlov.spb@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > Hi I think wiki is better than any attached docs. Could you please
> > > > create a
> > > > > page?
> > > > >
> > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <daradurvs@gmail.com
> >:
> > > > >
> > > > > > I prepared a description of the implemented solution and attached
> > it
> > > > > > to the issue [1].
> > > > > >
> > > > > > This should help during a review. Should I post the document into
> > wiki
> > > > or
> > > > > > IEP?
> > > > > >
> > > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> > please?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > > daradurvs@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi, Igniters! Good news!
> > > > > > >
> > > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > > >
> > > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > > >
> > > > > > > However, we need additional review from other Ignite experts.
> > > > > > >
> > > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > > >
> > > > > > > Could someone step in and do the review?
> > > > > > >
> > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > > dmekhanikov@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Pavel, could you assist?
> > > > > > > >
> > > > > > > > Does it make sense for .Net to specify service class name
> > instead
> > > > of
> > > > > > its
> > > > > > > > implementation?
> > > > > > > >
> > > > > > > > I think, it shouldn't be a problem.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > > daradurvs@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > I think that the replacement of serialized instance makes
> > sense
> > > > to me
> > > > > > > > > for Java part.
> > > > > > > > >
> > > > > > > > > But how it should work for .NET client?
> > > > > > > > >
> > > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > > dsetrakyan@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > nsamelchev@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hello, Igniters.
> > > > > > > > > > >
> > > > > > > > > > > I am working on task [1] that would replace serialized
> > > > service's
> > > > > > > > > instance
> > > > > > > > > > > by service's class name and properties map in
> > > > > > {ServiceConfiguration}.
> > > > > > > > > > >
> > > > > > > > > > > The task describes that we should use
> > > > > > > > > > > {String className} + {Map<String, Object> properties}
> > instead
> > > > > > {Service
> > > > > > > > > > > srvc}.
> > > > > > > > > > >
> > > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > > >
> > > > > > > > > > > 1. What about public methods?
> > > > > > > > > > > I suggest to mark them as deprecated and use class name
> > of
> > > > > > provided
> > > > > > > > > > > instance.
> > > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > > >
> > > > > > > > > > > @Deprecated
> > > > > > > > > > > public IgniteInternalFuture<?>
> > > > deployNodeSingleton(ClusterGroup
> > > > > > prj,
> > > > > > > > > > > String
> > > > > > > > > > > name, Service svc)
> > > > > > > > > > >
> > > > > > > > > > > public IgniteInternalFuture<?>
> > > > deployNodeSingleton(ClusterGroup
> > > > > > prj,
> > > > > > > > > > > String
> > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I think this makes sense, but I would like other
> > committers to
> > > > > > confirm.
> > > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> > mandatory
> > > > when
> > > > > > > > > deploying a
> > > > > > > > > > > service?
> > > > > > > > > > > Is it make sense to add deploying methods without it?
> For
> > > > > > example:
> > > > > > > > > > >
> > > > > > > > > > > public IgniteInternalFuture<?>
> > > > deployNodeSingleton(ClusterGroup
> > > > > > prj,
> > > > > > > > > > > String
> > > > > > > > > > > name, String srvcClsName)
> > > > > > > > > > >
> > > > > > > > > > > public IgniteInternalFuture<?>
> > > > deployNodeSingleton(ClusterGroup
> > > > > > prj,
> > > > > > > > > > > String
> > > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I would always ask the user to pass the property map, but
> > would
> > > > > > allow it
> > > > > > > > > to
> > > > > > > > > > be null.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >
>

Re: Service grid redesign

Posted by Denis Magda <dm...@apache.org>.
Vyacheslav,

What are the cases when the service can be redeployed? Affinity, failure,
etc., right. It would be good to list all the cases on the wiki and then
our tech writers will get everything documented.

--
Denis

On Thu, Nov 8, 2018 at 11:06 PM Vyacheslav Daradur <da...@gmail.com>
wrote:

> Denis,
>
> Services reassignment process takes into account previous assignments
> to avoid redundant redeployments.
> So, in the described case, ServiceA won't be moved from node1 to node2.
> On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org> wrote:
> >
> > Vyacheslav,
> >
> > First of all, thanks for archiving this milestone and rolling out these
> new
> > capabilities.
> >
> > Speaking of the topology change events [1], does the new architecture
> avoid
> > a running service redeployment when a new node joins? For instance, let's
> > say I have ServiceA running node1, then node2 joins and I don't want the
> > service to be redeployed to any other node.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
> >
> > --
> > Denis
> >
> > On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> >
> > > Dmitriy, I published documentation in wiki:
> > >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> > >
> > > Thank you!
> > > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com>
> > > wrote:
> > > >
> > > > Hi I think wiki is better than any attached docs. Could you please
> > > create a
> > > > page?
> > > >
> > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
> > > >
> > > > > I prepared a description of the implemented solution and attached
> it
> > > > > to the issue [1].
> > > > >
> > > > > This should help during a review. Should I post the document into
> wiki
> > > or
> > > > > IEP?
> > > > >
> > > > > I'd like to ask Ignite's experts review the solution [1] [2],
> please?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > > daradurvs@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi, Igniters! Good news!
> > > > > >
> > > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > > >
> > > > > > Nikolay Izhikov has reviewed implementation.
> > > > > >
> > > > > > However, we need additional review from other Ignite experts.
> > > > > >
> > > > > > Here is an umbrella ticket [1] and PR [2].
> > > > > >
> > > > > > Could someone step in and do the review?
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > > dmekhanikov@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > Pavel, could you assist?
> > > > > > >
> > > > > > > Does it make sense for .Net to specify service class name
> instead
> > > of
> > > > > its
> > > > > > > implementation?
> > > > > > >
> > > > > > > I think, it shouldn't be a problem.
> > > > > > >
> > > > > > > Denis
> > > > > > >
> > > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > > daradurvs@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > I think that the replacement of serialized instance makes
> sense
> > > to me
> > > > > > > > for Java part.
> > > > > > > >
> > > > > > > > But how it should work for .NET client?
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > > dsetrakyan@apache.org>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > nsamelchev@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hello, Igniters.
> > > > > > > > > >
> > > > > > > > > > I am working on task [1] that would replace serialized
> > > service's
> > > > > > > > instance
> > > > > > > > > > by service's class name and properties map in
> > > > > {ServiceConfiguration}.
> > > > > > > > > >
> > > > > > > > > > The task describes that we should use
> > > > > > > > > > {String className} + {Map<String, Object> properties}
> instead
> > > > > {Service
> > > > > > > > > > srvc}.
> > > > > > > > > >
> > > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > > >
> > > > > > > > > > 1. What about public methods?
> > > > > > > > > > I suggest to mark them as deprecated and use class name
> of
> > > > > provided
> > > > > > > > > > instance.
> > > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > > >
> > > > > > > > > > @Deprecated
> > > > > > > > > > public IgniteInternalFuture<?>
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, Service svc)
> > > > > > > > > >
> > > > > > > > > > public IgniteInternalFuture<?>
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I think this makes sense, but I would like other
> committers to
> > > > > confirm.
> > > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > 2. Is {Map<String, Object> properties} parameter
> mandatory
> > > when
> > > > > > > > deploying a
> > > > > > > > > > service?
> > > > > > > > > > Is it make sense to add deploying methods without it? For
> > > > > example:
> > > > > > > > > >
> > > > > > > > > > public IgniteInternalFuture<?>
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, String srvcClsName)
> > > > > > > > > >
> > > > > > > > > > public IgniteInternalFuture<?>
> > > deployNodeSingleton(ClusterGroup
> > > > > prj,
> > > > > > > > > > String
> > > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I would always ask the user to pass the property map, but
> would
> > > > > allow it
> > > > > > > > to
> > > > > > > > > be null.
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best Regards, Vyacheslav D.
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Denis,

Services reassignment process takes into account previous assignments
to avoid redundant redeployments.
So, in the described case, ServiceA won't be moved from node1 to node2.
On Fri, Nov 9, 2018 at 4:41 AM Denis Magda <dm...@apache.org> wrote:
>
> Vyacheslav,
>
> First of all, thanks for archiving this milestone and rolling out these new
> capabilities.
>
> Speaking of the topology change events [1], does the new architecture avoid
> a running service redeployment when a new node joins? For instance, let's
> say I have ServiceA running node1, then node2 joins and I don't want the
> service to be redeployed to any other node.
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange
>
> --
> Denis
>
> On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <da...@gmail.com>
> wrote:
>
> > Dmitriy, I published documentation in wiki:
> > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
> >
> > Thank you!
> > On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com>
> > wrote:
> > >
> > > Hi I think wiki is better than any attached docs. Could you please
> > create a
> > > page?
> > >
> > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
> > >
> > > > I prepared a description of the implemented solution and attached it
> > > > to the issue [1].
> > > >
> > > > This should help during a review. Should I post the document into wiki
> > or
> > > > IEP?
> > > >
> > > > I'd like to ask Ignite's experts review the solution [1] [2], please?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > [2] https://github.com/apache/ignite/pull/4434
> > > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > >
> > > > > Hi, Igniters! Good news!
> > > > >
> > > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > > >
> > > > > Nikolay Izhikov has reviewed implementation.
> > > > >
> > > > > However, we need additional review from other Ignite experts.
> > > > >
> > > > > Here is an umbrella ticket [1] and PR [2].
> > > > >
> > > > > Could someone step in and do the review?
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > > [2] https://github.com/apache/ignite/pull/4434
> > > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> > dmekhanikov@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > Pavel, could you assist?
> > > > > >
> > > > > > Does it make sense for .Net to specify service class name instead
> > of
> > > > its
> > > > > > implementation?
> > > > > >
> > > > > > I think, it shouldn't be a problem.
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> > daradurvs@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > I think that the replacement of serialized instance makes sense
> > to me
> > > > > > > for Java part.
> > > > > > >
> > > > > > > But how it should work for .NET client?
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > nsamelchev@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hello, Igniters.
> > > > > > > > >
> > > > > > > > > I am working on task [1] that would replace serialized
> > service's
> > > > > > > instance
> > > > > > > > > by service's class name and properties map in
> > > > {ServiceConfiguration}.
> > > > > > > > >
> > > > > > > > > The task describes that we should use
> > > > > > > > > {String className} + {Map<String, Object> properties} instead
> > > > {Service
> > > > > > > > > srvc}.
> > > > > > > > >
> > > > > > > > > I'd like to clarify the following questions:
> > > > > > > > >
> > > > > > > > > 1. What about public methods?
> > > > > > > > > I suggest to mark them as deprecated and use class name of
> > > > provided
> > > > > > > > > instance.
> > > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > > >
> > > > > > > > > @Deprecated
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, Service svc)
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I think this makes sense, but I would like other committers to
> > > > confirm.
> > > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > > >
> > > > > > > >
> > > > > > > > > 2. Is {Map<String, Object> properties} parameter mandatory
> > when
> > > > > > > deploying a
> > > > > > > > > service?
> > > > > > > > > Is it make sense to add deploying methods without it? For
> > > > example:
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName)
> > > > > > > > >
> > > > > > > > > public IgniteInternalFuture<?>
> > deployNodeSingleton(ClusterGroup
> > > > prj,
> > > > > > > > > String
> > > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > > >
> > > > > > > >
> > > > > > > > I would always ask the user to pass the property map, but would
> > > > allow it
> > > > > > > to
> > > > > > > > be null.
> > > > > > > >
> > > > > > > > D.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Denis Magda <dm...@apache.org>.
Vyacheslav,

First of all, thanks for archiving this milestone and rolling out these new
capabilities.

Speaking of the topology change events [1], does the new architecture avoid
a running service redeployment when a new node joins? For instance, let's
say I have ServiceA running node1, then node2 joins and I don't want the
service to be redeployed to any other node.

[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584#ServiceGridredesign.Phase1.Implementationdetails.-Topologychange

--
Denis

On Wed, Nov 7, 2018 at 7:04 AM Vyacheslav Daradur <da...@gmail.com>
wrote:

> Dmitriy, I published documentation in wiki:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584
>
> Thank you!
> On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com>
> wrote:
> >
> > Hi I think wiki is better than any attached docs. Could you please
> create a
> > page?
> >
> > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
> >
> > > I prepared a description of the implemented solution and attached it
> > > to the issue [1].
> > >
> > > This should help during a review. Should I post the document into wiki
> or
> > > IEP?
> > >
> > > I'd like to ask Ignite's experts review the solution [1] [2], please?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > [2] https://github.com/apache/ignite/pull/4434
> > > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > > >
> > > > Hi, Igniters! Good news!
> > > >
> > > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > > >
> > > > Nikolay Izhikov has reviewed implementation.
> > > >
> > > > However, we need additional review from other Ignite experts.
> > > >
> > > > Here is an umbrella ticket [1] and PR [2].
> > > >
> > > > Could someone step in and do the review?
> > > >
> > > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > > [2] https://github.com/apache/ignite/pull/4434
> > > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <
> dmekhanikov@gmail.com>
> > > wrote:
> > > > >
> > > > > Pavel, could you assist?
> > > > >
> > > > > Does it make sense for .Net to specify service class name instead
> of
> > > its
> > > > > implementation?
> > > > >
> > > > > I think, it shouldn't be a problem.
> > > > >
> > > > > Denis
> > > > >
> > > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <
> daradurvs@gmail.com>
> > > wrote:
> > > > >
> > > > > > I think that the replacement of serialized instance makes sense
> to me
> > > > > > for Java part.
> > > > > >
> > > > > > But how it should work for .NET client?
> > > > > >
> > > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > > dsetrakyan@apache.org>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > nsamelchev@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello, Igniters.
> > > > > > > >
> > > > > > > > I am working on task [1] that would replace serialized
> service's
> > > > > > instance
> > > > > > > > by service's class name and properties map in
> > > {ServiceConfiguration}.
> > > > > > > >
> > > > > > > > The task describes that we should use
> > > > > > > > {String className} + {Map<String, Object> properties} instead
> > > {Service
> > > > > > > > srvc}.
> > > > > > > >
> > > > > > > > I'd like to clarify the following questions:
> > > > > > > >
> > > > > > > > 1. What about public methods?
> > > > > > > > I suggest to mark them as deprecated and use class name of
> > > provided
> > > > > > > > instance.
> > > > > > > > Also to add deploying methods with new parameters:
> > > > > > > >
> > > > > > > > @Deprecated
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, Service svc)
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > >
> > > > > > >
> > > > > > > I think this makes sense, but I would like other committers to
> > > confirm.
> > > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > > >
> > > > > > >
> > > > > > > > 2. Is {Map<String, Object> properties} parameter mandatory
> when
> > > > > > deploying a
> > > > > > > > service?
> > > > > > > > Is it make sense to add deploying methods without it? For
> > > example:
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName)
> > > > > > > >
> > > > > > > > public IgniteInternalFuture<?>
> deployNodeSingleton(ClusterGroup
> > > prj,
> > > > > > > > String
> > > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > > >
> > > > > > >
> > > > > > > I would always ask the user to pass the property map, but would
> > > allow it
> > > > > > to
> > > > > > > be null.
> > > > > > >
> > > > > > > D.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best Regards, Vyacheslav D.
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
Dmitriy, I published documentation in wiki:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95654584

Thank you!
On Wed, Nov 7, 2018 at 5:10 PM Dmitriy Pavlov <dp...@gmail.com> wrote:
>
> Hi I think wiki is better than any attached docs. Could you please create a
> page?
>
> ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:
>
> > I prepared a description of the implemented solution and attached it
> > to the issue [1].
> >
> > This should help during a review. Should I post the document into wiki or
> > IEP?
> >
> > I'd like to ask Ignite's experts review the solution [1] [2], please?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > [2] https://github.com/apache/ignite/pull/4434
> > On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > >
> > > Hi, Igniters! Good news!
> > >
> > > Service Grid Redesign Phase 1 - is in Patch Available now.
> > >
> > > Nikolay Izhikov has reviewed implementation.
> > >
> > > However, we need additional review from other Ignite experts.
> > >
> > > Here is an umbrella ticket [1] and PR [2].
> > >
> > > Could someone step in and do the review?
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > > [2] https://github.com/apache/ignite/pull/4434
> > > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <dm...@gmail.com>
> > wrote:
> > > >
> > > > Pavel, could you assist?
> > > >
> > > > Does it make sense for .Net to specify service class name instead of
> > its
> > > > implementation?
> > > >
> > > > I think, it shouldn't be a problem.
> > > >
> > > > Denis
> > > >
> > > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <da...@gmail.com>
> > wrote:
> > > >
> > > > > I think that the replacement of serialized instance makes sense to me
> > > > > for Java part.
> > > > >
> > > > > But how it should work for .NET client?
> > > > >
> > > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> > dsetrakyan@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > nsamelchev@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello, Igniters.
> > > > > > >
> > > > > > > I am working on task [1] that would replace serialized service's
> > > > > instance
> > > > > > > by service's class name and properties map in
> > {ServiceConfiguration}.
> > > > > > >
> > > > > > > The task describes that we should use
> > > > > > > {String className} + {Map<String, Object> properties} instead
> > {Service
> > > > > > > srvc}.
> > > > > > >
> > > > > > > I'd like to clarify the following questions:
> > > > > > >
> > > > > > > 1. What about public methods?
> > > > > > > I suggest to mark them as deprecated and use class name of
> > provided
> > > > > > > instance.
> > > > > > > Also to add deploying methods with new parameters:
> > > > > > >
> > > > > > > @Deprecated
> > > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, Service svc)
> > > > > > >
> > > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > >
> > > > > >
> > > > > > I think this makes sense, but I would like other committers to
> > confirm.
> > > > > > Perhaps Vladimir Ozerov should comment here.
> > > > > >
> > > > > >
> > > > > > > 2. Is {Map<String, Object> properties} parameter mandatory when
> > > > > deploying a
> > > > > > > service?
> > > > > > > Is it make sense to add deploying methods without it? For
> > example:
> > > > > > >
> > > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName)
> > > > > > >
> > > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> > prj,
> > > > > > > String
> > > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > > >
> > > > > >
> > > > > > I would always ask the user to pass the property map, but would
> > allow it
> > > > > to
> > > > > > be null.
> > > > > >
> > > > > > D.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best Regards, Vyacheslav D.
> > > > >
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
> >



-- 
Best Regards, Vyacheslav D.

Re: Service grid redesign

Posted by Dmitriy Pavlov <dp...@gmail.com>.
Hi I think wiki is better than any attached docs. Could you please create a
page?

ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <da...@gmail.com>:

> I prepared a description of the implemented solution and attached it
> to the issue [1].
>
> This should help during a review. Should I post the document into wiki or
> IEP?
>
> I'd like to ask Ignite's experts review the solution [1] [2], please?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9607
> [2] https://github.com/apache/ignite/pull/4434
> On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <da...@gmail.com>
> wrote:
> >
> > Hi, Igniters! Good news!
> >
> > Service Grid Redesign Phase 1 - is in Patch Available now.
> >
> > Nikolay Izhikov has reviewed implementation.
> >
> > However, we need additional review from other Ignite experts.
> >
> > Here is an umbrella ticket [1] and PR [2].
> >
> > Could someone step in and do the review?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9607
> > [2] https://github.com/apache/ignite/pull/4434
> > On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <dm...@gmail.com>
> wrote:
> > >
> > > Pavel, could you assist?
> > >
> > > Does it make sense for .Net to specify service class name instead of
> its
> > > implementation?
> > >
> > > I think, it shouldn't be a problem.
> > >
> > > Denis
> > >
> > > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <da...@gmail.com>
> wrote:
> > >
> > > > I think that the replacement of serialized instance makes sense to me
> > > > for Java part.
> > > >
> > > > But how it should work for .NET client?
> > > >
> > > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > > > wrote:
> > > > >
> > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> nsamelchev@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hello, Igniters.
> > > > > >
> > > > > > I am working on task [1] that would replace serialized service's
> > > > instance
> > > > > > by service's class name and properties map in
> {ServiceConfiguration}.
> > > > > >
> > > > > > The task describes that we should use
> > > > > > {String className} + {Map<String, Object> properties} instead
> {Service
> > > > > > srvc}.
> > > > > >
> > > > > > I'd like to clarify the following questions:
> > > > > >
> > > > > > 1. What about public methods?
> > > > > > I suggest to mark them as deprecated and use class name of
> provided
> > > > > > instance.
> > > > > > Also to add deploying methods with new parameters:
> > > > > >
> > > > > > @Deprecated
> > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, Service svc)
> > > > > >
> > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > >
> > > > >
> > > > > I think this makes sense, but I would like other committers to
> confirm.
> > > > > Perhaps Vladimir Ozerov should comment here.
> > > > >
> > > > >
> > > > > > 2. Is {Map<String, Object> properties} parameter mandatory when
> > > > deploying a
> > > > > > service?
> > > > > > Is it make sense to add deploying methods without it? For
> example:
> > > > > >
> > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName)
> > > > > >
> > > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup
> prj,
> > > > > > String
> > > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > > >
> > > > >
> > > > > I would always ask the user to pass the property map, but would
> allow it
> > > > to
> > > > > be null.
> > > > >
> > > > > D.
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> >
> >
> >
> > --
> > Best Regards, Vyacheslav D.
>
>
>
> --
> Best Regards, Vyacheslav D.
>

Re: Service grid redesign

Posted by Vyacheslav Daradur <da...@gmail.com>.
I prepared a description of the implemented solution and attached it
to the issue [1].

This should help during a review. Should I post the document into wiki or IEP?

I'd like to ask Ignite's experts review the solution [1] [2], please?

[1] https://issues.apache.org/jira/browse/IGNITE-9607
[2] https://github.com/apache/ignite/pull/4434
On Wed, Oct 31, 2018 at 5:04 PM Vyacheslav Daradur <da...@gmail.com> wrote:
>
> Hi, Igniters! Good news!
>
> Service Grid Redesign Phase 1 - is in Patch Available now.
>
> Nikolay Izhikov has reviewed implementation.
>
> However, we need additional review from other Ignite experts.
>
> Here is an umbrella ticket [1] and PR [2].
>
> Could someone step in and do the review?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9607
> [2] https://github.com/apache/ignite/pull/4434
> On Sat, Aug 18, 2018 at 11:44 AM Denis Mekhanikov <dm...@gmail.com> wrote:
> >
> > Pavel, could you assist?
> >
> > Does it make sense for .Net to specify service class name instead of its
> > implementation?
> >
> > I think, it shouldn't be a problem.
> >
> > Denis
> >
> > On Sat, Aug 18, 2018, 11:33 Vyacheslav Daradur <da...@gmail.com> wrote:
> >
> > > I think that the replacement of serialized instance makes sense to me
> > > for Java part.
> > >
> > > But how it should work for .NET client?
> > >
> > > On Tue, Aug 14, 2018 at 4:07 PM Dmitriy Setrakyan <ds...@apache.org>
> > > wrote:
> > > >
> > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <ns...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I am working on task [1] that would replace serialized service's
> > > instance
> > > > > by service's class name and properties map in {ServiceConfiguration}.
> > > > >
> > > > > The task describes that we should use
> > > > > {String className} + {Map<String, Object> properties} instead {Service
> > > > > srvc}.
> > > > >
> > > > > I'd like to clarify the following questions:
> > > > >
> > > > > 1. What about public methods?
> > > > > I suggest to mark them as deprecated and use class name of provided
> > > > > instance.
> > > > > Also to add deploying methods with new parameters:
> > > > >
> > > > > @Deprecated
> > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, Service svc)
> > > > >
> > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > >
> > > >
> > > > I think this makes sense, but I would like other committers to confirm.
> > > > Perhaps Vladimir Ozerov should comment here.
> > > >
> > > >
> > > > > 2. Is {Map<String, Object> properties} parameter mandatory when
> > > deploying a
> > > > > service?
> > > > > Is it make sense to add deploying methods without it? For example:
> > > > >
> > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName)
> > > > >
> > > > > public IgniteInternalFuture<?> deployNodeSingleton(ClusterGroup prj,
> > > > > String
> > > > > name, String srvcClsName, Map<String, Object> prop)
> > > > >
> > > >
> > > > I would always ask the user to pass the property map, but would allow it
> > > to
> > > > be null.
> > > >
> > > > D.
> > >
> > >
> > >
> > > --
> > > Best Regards, Vyacheslav D.
> > >
>
>
>
> --
> Best Regards, Vyacheslav D.



-- 
Best Regards, Vyacheslav D.