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 |
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. |
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. |
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. > |
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. |
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. |
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. > |
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. |
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. > |
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. > > > |
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. > |
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. |
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. > |
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. > > > |
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. > > > |
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. > > > > > |
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. |
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. |
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. > |
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. |
Free forum by Nabble | Edit this page |