Service grid redesign

classic Classic list List threaded Threaded
137 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Nikita Amelchev
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)

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)

Thoughts?

1. https://issues.apache.org/jira/browse/IGNITE-8366

2018-08-09 18:21 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:

> Versions will complicate the implementation and will not be done in 2.7. I
> would vote for the hot redeployment for now and add versions in 2.8.
>
> D.
>
> On Thu, Aug 9, 2018 at 10:06 AM, Anton Vinogradov <[hidden email]> wrote:
>
> > Real case is A/B testing.
> > When you want to allow new service usage only to 0.1% of users.
> > And only when you sure it works then replace all v1 with v2.
> >
> > So, I vote for versions.
> > Let's do this in maven way (exact version, range, RELEASE or LATEST)
> >
> > чт, 9 авг. 2018 г. в 17:55, Dmitriy Setrakyan <[hidden email]>:
> >
> > > Vyacheslav,
> > >
> > > For the case you are describing, I would take the same approach as we
> > have
> > > for compute tasks. Keep the older version around only as long as there
> > are
> > > active requests and then undeploy it automatically. No need to allow it
> > > linger around indefinitely.
> > >
> > > D.
> > >
> > > On Thu, Aug 9, 2018 at 9:52 AM, Vyacheslav Daradur <
> [hidden email]>
> > > wrote:
> > >
> > > > Dmitry, it's not only about hot redeployment.
> > > >
> > > > Denis, I don't see such use case, because of the answer in a
> different
> > > > front.
> > > >
> > > > It relates to the best practices of SOA versioning [1] [2].
> > > >
> > > > For example:
> > > > * we have a cluster with service [name="MySevice", v="1"];
> > > > * I want to upgrade service to [name="MySevice", v="2"], but I have
> > > > clients which are using [name="MySevice", v="1"] and can't stop
> > > > processing;
> > > > * With service versioning, we are able to deploy new service near
> > > > existing service, then switch clients and undeploy outdated service.
> > > >
> > > > My only question is: are we going to implement such a feature [3] or
> > > > not? Maybe PMC don't see such feature in Service Grid roadmap.
> > > > IMO it's a good feature for a microservices platform.
> > > >
> > > >
> > > > [1] https://www.thbs.com/thbs-insights/soa-service-
> > > > versioning-best-practices
> > > > [2] https://www.ibm.com/blogs/bluemix/2017/08/rapidly-
> > > > developing-applications-part-6-exposing-and-versioning-apis/
> > > > [3] https://issues.apache.org/jira/browse/IGNITE-6069
> > > > On Thu, Aug 9, 2018 at 5:48 PM Dmitriy Setrakyan <
> > [hidden email]>
> > > > wrote:
> > > > >
> > > > > Guys,
> > > > >
> > > > > I thought this was about automatic service redeployment, which
> should
> > > > have
> > > > > been a part of the current IEP, no? Can you please clarify?
> > > > >
> > > > > D.
> > > > >
> > > > > On Thu, Aug 9, 2018 at 9:26 AM, Denis Mekhanikov <
> > > [hidden email]>
> > > > > wrote:
> > > > >
> > > > > > Vyacheslav,
> > > > > >
> > > > > > It looks like an overcomplication to me.
> > > > > > Could you describe a case, that can be solved using versioning,
> but
> > > not
> > > > > > naming?
> > > > > >
> > > > > > Denis
> > > > > >
> > > > > > чт, 9 авг. 2018 г. в 16:56, Vyacheslav Daradur <
> > [hidden email]
> > > >:
> > > > > >
> > > > > > > Denis, it's not about different users services implementations.
> > > > > > >
> > > > > > > A real use case is user's services API versioning which is
> being
> > > used
> > > > > > > widely t in SOAP/REST microservices infrastructure.
> > > > > > >
> > > > > > > In my opinion, it is about services with the same name and the
> > same
> > > > > > > full class name, but different classes versions for example in
> > > > > > > different classloaders.
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Aug 9, 2018 at 4:41 PM Denis Mekhanikov <
> > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I don't think, that we really need this feature.
> > > > > > > > It seems to me, that if you want to use a different
> > > implementation
> > > > of a
> > > > > > > > service, you can assign a different name to it.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > чт, 9 авг. 2018 г. в 16:32, Dmitriy Setrakyan <
> > > > [hidden email]>:
> > > > > > > >
> > > > > > > > > On Thu, Aug 9, 2018 at 4:41 AM, Vyacheslav Daradur <
> > > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi, Igniters!
> > > > > > > > > >
> > > > > > > > > > I found a ticket about a service’s versioning [1].
> > > > > > > > > >
> > > > > > > > > > It’s out of scope IEP-17, but if we are going to
> implement
> > > this
> > > > > > > > > > feature we should build a base in the first iteration of
> > > IEP-17
> > > > > > > > > > because of change messages formats.
> > > > > > > > > >
> > > > > > > > > > In case of the versioning which assumes that we are able
> to
> > > > host
> > > > > > > > > > services with the same name, but with different
> > > class/version,
> > > > we
> > > > > > > > > > should introduce *service’s id* to manage service’s
> > lifecycle
> > > > > > instead
> > > > > > > > > > of service’s name.
> > > > > > > > > >
> > > > > > > > > > Thoughts?
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > My only concern would be on the usability side. Is user
> going
> > > to
> > > > have
> > > > > > > to
> > > > > > > > > deal with IDs now, or will it be handled internally?
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best Regards, Vyacheslav D.
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> >
>



--
Best wishes,
Amelchev Nikita
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

dsetrakyan
On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> wrote:

>
> On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <[hidden email]>
> 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Denis Mekhanikov
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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <[hidden email]>
> > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> > >
> > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <[hidden email]>
> > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > wrote:
> > > >
> > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <[hidden email]>
> > > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Dmitriy Pavlov
Hi I think wiki is better than any attached docs. Could you please create a
page?

ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > wrote:
> > > > >
> > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> [hidden email]>
> > > > > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> wrote:

>
> Hi I think wiki is better than any attached docs. Could you please create a
> page?
>
> ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > [hidden email]>
> > > > > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Nikolay Izhikov-2
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 [hidden email]:

> 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 <[hidden email]>
> wrote:
> >
> > Hi I think wiki is better than any attached docs. Could you please
> create a
> > page?
> >
> > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
> >
> > > 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 <
> [hidden email]>
> > > 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 <
> [hidden email]>
> > > 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 <
> [hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > [hidden email]>
> > > > > > > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

yzhdanov
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 <[hidden email]>:

> 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 [hidden email]:
>
> > 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 <[hidden email]>
> > wrote:
> > >
> > > Hi I think wiki is better than any attached docs. Could you please
> > create a
> > > page?
> > >
> > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
> > >
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > [hidden email]>
> > > > > > > > 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.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

dmagda
In reply to this post by daradurvs
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 <[hidden email]>
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 <[hidden email]>
> wrote:
> >
> > Hi I think wiki is better than any attached docs. Could you please
> create a
> > page?
> >
> > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
> >
> > > 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 <
> [hidden email]>
> > > 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 <
> [hidden email]>
> > > 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 <
> [hidden email]>
> > > 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 <
> > > [hidden email]>
> > > > > > wrote:
> > > > > > >
> > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > [hidden email]>
> > > > > > > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > wrote:
> > >
> > > Hi I think wiki is better than any attached docs. Could you please
> > create a
> > > page?
> > >
> > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
> > >
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > [hidden email]>
> > > > 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 <
> > > > [hidden email]>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > [hidden email]>
> > > > > > > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

dmagda
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
> > 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 <[hidden email]>
> > > wrote:
> > > >
> > > > Hi I think wiki is better than any attached docs. Could you please
> > > create a
> > > > page?
> > > >
> > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]>:
> > > >
> > > > > 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 <
> > > [hidden email]>
> > > > > 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 <
> > > [hidden email]>
> > > > > 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 <
> > > [hidden email]>
> > > > > 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 <
> > > > > [hidden email]>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > [hidden email]>
> > > > > > > > > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]
> >
> > > 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 <[hidden email]
> >
> > > > wrote:
> > > > >
> > > > > Hi I think wiki is better than any attached docs. Could you please
> > > > create a
> > > > > page?
> > > > >
> > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]
> >:
> > > > >
> > > > > > 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 <
> > > > [hidden email]>
> > > > > > 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 <
> > > > [hidden email]>
> > > > > > 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 <
> > > > [hidden email]>
> > > > > > 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 <
> > > > > > [hidden email]>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > [hidden email]>
> > > > > > > > > > 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.
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Nikolay Izhikov-2
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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]> 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 <[hidden email]
> > > > 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 <[hidden email]
> > > > > wrote:
> > > > > >
> > > > > > Hi I think wiki is better than any attached docs. Could you please
> > > > >
> > > > > create a
> > > > > > page?
> > > > > >
> > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <[hidden email]
> > >
> > > :
> > > > > >
> > > > > > > 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 <
> > > > >
> > > > > [hidden email]>
> > > > > > > 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 <
> > > > >
> > > > > [hidden email]>
> > > > > > > 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 <
> > > > >
> > > > > [hidden email]>
> > > > > > > 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 <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > > > > > > 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.
> > >

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Denis Mekhanikov
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 <[hidden email]>:

> 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 <[hidden email]>:
> >
> > > 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 <
> [hidden email]>
> > > 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 <[hidden email]>
> 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 <
> [hidden email]
> > > > > 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 <
> [hidden email]
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi I think wiki is better than any attached docs. Could you
> please
> > > > > >
> > > > > > create a
> > > > > > > page?
> > > > > > >
> > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> [hidden email]
> > > >
> > > > :
> > > > > > >
> > > > > > > > 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 <
> > > > > >
> > > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > >
> > > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > >
> > > > > > [hidden email]>
> > > > > > > > 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 <
> > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > > > > > > 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.
> > > >
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
Denis, Yakov, feel free to contact me directly in case of questions. Thanks!

On Sun, Nov 11, 2018 at 10:09 PM Denis Mekhanikov <[hidden email]> 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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> > >
> > > > 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 <
> > [hidden email]>
> > > > 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 <[hidden email]>
> > 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 <
> > [hidden email]
> > > > > > 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 <
> > [hidden email]
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi I think wiki is better than any attached docs. Could you
> > please
> > > > > > >
> > > > > > > create a
> > > > > > > > page?
> > > > > > > >
> > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > [hidden email]
> > > > >
> > > > > :
> > > > > > > >
> > > > > > > > > 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 <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > > > > 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 <
> > > > > > > > >
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > > >
> > > > > > > > > [hidden email]>
> > > > > > > > > > > > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > > >
> > > > > 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 <
> > > [hidden email]>
> > > > > 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 <[hidden email]>
> > > 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 <
> > > [hidden email]
> > > > > > > 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 <
> > > [hidden email]
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi I think wiki is better than any attached docs. Could you
> > > please
> > > > > > > >
> > > > > > > > create a
> > > > > > > > > page?
> > > > > > > > >
> > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > [hidden email]
> > > > > >
> > > > > > :
> > > > > > > > >
> > > > > > > > > > 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 <
> > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > >
> > > > > > > > [hidden email]>
> > > > > > > > > > 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 <
> > > > > > > > > >
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita Amelchev <
> > > > > > > > > >
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > 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.
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

Denis Mekhanikov
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 <[hidden email]>:

> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>:
> > >
> > > > 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 <[hidden email]>:
> > > > >
> > > > > > 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 <
> > > > [hidden email]>
> > > > > > 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 <[hidden email]>
> > > > 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 <
> > > > [hidden email]
> > > > > > > > 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 <
> > > > [hidden email]
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Hi I think wiki is better than any attached docs. Could
> you
> > > > please
> > > > > > > > >
> > > > > > > > > create a
> > > > > > > > > > page?
> > > > > > > > > >
> > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > [hidden email]
> > > > > > >
> > > > > > > :
> > > > > > > > > >
> > > > > > > > > > > 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 <
> > > > > > > > >
> > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > >
> > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > >
> > > > > > > > > [hidden email]>
> > > > > > > > > > > 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 <
> > > > > > > > > > >
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> Amelchev <
> > > > > > > > > > >
> > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Service grid redesign

daradurvs
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 <[hidden email]> 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 <[hidden email]>:
>
> > 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <[hidden email]>:
> > > >
> > > > > 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 <[hidden email]>:
> > > > > >
> > > > > > > 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 <
> > > > > [hidden email]>
> > > > > > > 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 <[hidden email]>
> > > > > 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 <
> > > > > [hidden email]
> > > > > > > > > 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 <
> > > > > [hidden email]
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi I think wiki is better than any attached docs. Could
> > you
> > > > > please
> > > > > > > > > >
> > > > > > > > > > create a
> > > > > > > > > > > page?
> > > > > > > > > > >
> > > > > > > > > > > ср, 7 нояб. 2018 г., 14:39 Vyacheslav Daradur <
> > > > > [hidden email]
> > > > > > > >
> > > > > > > > :
> > > > > > > > > > >
> > > > > > > > > > > > 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 <
> > > > > > > > > >
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > >
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > >
> > > > > > > > > > [hidden email]>
> > > > > > > > > > > > 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 <
> > > > > > > > > > > >
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Aug 14, 2018 at 6:10 AM, Nikita
> > Amelchev <
> > > > > > > > > > > >
> > > > > > > > > > > > [hidden email]>
> > > > > > > > > > > > > > > > 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.
1234567