You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Ilya Lantukh <il...@gridgain.com> on 2017/08/15 15:18:19 UTC
Service versioning
Igniters,
Our current ServiceGrid implementation lacks several important features,
one of which is ability to upgrade Service without downtime.
I've created ticket to add this feature:
https://issues.apache.org/jira/browse/IGNITE-6069.
To implement it, the following problems must be solved:
- currently we can store only one BinaryMetadata instance for given
classname - if you change Service class implementation and then try to
deploy it, you might get an exception like
"org.apache.ignite.binary.BinaryObjectException: Binary type has different
field types". It can be solved by making (className, version) unique
metadata identifier. We can use serialVersionUuid as version.
- ServiceProxy must be aware of actual version and know if service is
currently being upgraded. If user tries to execute any method during
upgrade, proxy should implicitly wait until new version is ready. We
already have similar logic in IgniteCacheProxyImpl.
- To effectively and conveniently migrate service state to newer version,
we should add method to Service interface that will be executed before
start if older version was present. To keep API compatible, I suggest to
introduce interface UpgradableService (extends Service).
Any critique and suggestions are welcome.
--
Best regards,
Ilya
Re: Service versioning
Posted by Denis Mekhanikov <dm...@gmail.com>.
Guys,
Let me remind you that services still don't support peer class loading:
https://issues.apache.org/jira/browse/IGNITE-975
I think, it should be fixed as well, because versioning is pretty useless
without ability to change implementation without downtime. Also I've seen a
lot of questions from users about it, so people expect it to work.
Another thing: I think, it will be more convenient if user will be able to
specify version manually in the configuration instead of
using serialVersionUID. It will allow versions to be assigned to different
configurations of a service object. If we use serialVersionUID as a
version, then changes of properties of service beans will not be tracked.
Also you can't tell by serialVersionUID, which version is new and which is
old, because this is often just a result of some hash function. Specifying
versions manually will solve this problem.
What do you guys think?
пт, 18 авг. 2017 г. в 12:33, Ilya Lantukh <il...@gridgain.com>:
> Sergey,
>
> I think the ticket covers single atomic piece of functionality.
>
> I'd prefer to avoid to separately address flaws in current service upgrade
> process because this process had never been designed, implemented and
> supported. Yes, in current ServiceGrid implementation you can (technically)
> replace existing service with newer implementation, and there are a number
> of potential problems you might encounter while doing so. But it doesn't
> make much sense to me to fix flaws in functionality that officially doesn't
> exist. Those issues should be addressed in the scope of service versioning.
>
> Use-cases that you described are interesting and we should try to support
> them, but I don't think that we should implement functionality for all
> possible cases in single step. I'll think how we can technically support
> them in Ignite and I'm open to suggestions from you (and anyone else).
>
> I don't think I understand your concept of ServiceRegistry in the same way
> you do. Could you please describe it in more detail?
>
> Thanks.
>
> On Wed, Aug 16, 2017 at 6:06 PM, Sergey Chugunov <
> sergey.chugunov@gmail.com>
> wrote:
>
> > Ilya,
> >
> > I think the proposed change definitely makes sense.
> >
> > At the same time I think the scope of the ticket is too broad. It covers
> at
> > least two different aspects of service grid functionality:
> >
> > - Very specific issue of service upgrade process which is caused by
> > current design flaw (although it's not a bug).
> > - Very high-level suggestions about improving upgrade process in
> > general.
> >
> >
> > I think it is better to separate these things. Lets firstly address
> item#1
> > and then reiterate on #2.
> >
> > Managing services deployment in distributed system is a non-trivial task
> > with a lot of options and different requirements; all changes and
> > improvements must be designed thoughtfully.
> >
> > E.g. for the requirement from the ticket that all services under the same
> > name must be of the same version: what if a user wants to test a new
> > implementation transparently to the clients of the cluster?
> > It would be convenient for that user to be able to redeploy only one
> > instance of the service to the newer version (without touching other
> > instances) and see if any client reports a problem.
> >
> > Also I'm familiar with an example when a system with service-like
> entities
> > connected to it supported both upgrades and downgrades: it was possible
> to
> > connect new versions of services to the "parent" system, send some work
> to
> > them but in case of any issues with newer version it was always possible
> to
> > quickly fall back to the previous one known to be stable.
> > This use case isn't covered in your ticket at all although I think it is
> > kind of obvious feature.
> >
> > From my point of view Ignite just doesn't have necessary internal
> > abstractions to support rich service functionality with managing
> versions,
> > upgrades/downgrades and so on.
> > Something like distributed ServiceRegistry concept with managing API to
> the
> > user. We don't have anything like this now.
> >
> > So I think we should focus on addressing existing issue described in
> item#1
> > and start a new discussion about ways to improve our service grid
> > capabilities in a separate thread.
> > Item#2 will be addressed automatically as part of that discussion.
> >
> > Makes sense?
> >
> > Thanks,
> > Sergey.
> >
> > On Wed, Aug 16, 2017 at 2:22 AM, Denis Magda <dm...@apache.org> wrote:
> >
> > > Ilya,
> > >
> > > Every Service Grid user will welcome this feature. Fully for it.
> > >
> > > Mentioned in the ticket that it has to be documented before the ticket
> is
> > > closed.
> > >
> > > —
> > > Denis
> > >
> > > > On Aug 15, 2017, at 8:18 AM, Ilya Lantukh <il...@gridgain.com>
> > wrote:
> > > >
> > > > Igniters,
> > > >
> > > > Our current ServiceGrid implementation lacks several important
> > features,
> > > > one of which is ability to upgrade Service without downtime.
> > > >
> > > > I've created ticket to add this feature:
> > > > https://issues.apache.org/jira/browse/IGNITE-6069.
> > > >
> > > > To implement it, the following problems must be solved:
> > > > - currently we can store only one BinaryMetadata instance for given
> > > > classname - if you change Service class implementation and then try
> to
> > > > deploy it, you might get an exception like
> > > > "org.apache.ignite.binary.BinaryObjectException: Binary type has
> > > different
> > > > field types". It can be solved by making (className, version) unique
> > > > metadata identifier. We can use serialVersionUuid as version.
> > > > - ServiceProxy must be aware of actual version and know if service is
> > > > currently being upgraded. If user tries to execute any method during
> > > > upgrade, proxy should implicitly wait until new version is ready. We
> > > > already have similar logic in IgniteCacheProxyImpl.
> > > > - To effectively and conveniently migrate service state to newer
> > version,
> > > > we should add method to Service interface that will be executed
> before
> > > > start if older version was present. To keep API compatible, I suggest
> > to
> > > > introduce interface UpgradableService (extends Service).
> > > >
> > > > Any critique and suggestions are welcome.
> > > >
> > > > --
> > > > Best regards,
> > > > Ilya
> > >
> > >
> >
>
>
>
> --
> Best regards,
> Ilya
>
Re: Service versioning
Posted by Ilya Lantukh <il...@gridgain.com>.
Sergey,
I think the ticket covers single atomic piece of functionality.
I'd prefer to avoid to separately address flaws in current service upgrade
process because this process had never been designed, implemented and
supported. Yes, in current ServiceGrid implementation you can (technically)
replace existing service with newer implementation, and there are a number
of potential problems you might encounter while doing so. But it doesn't
make much sense to me to fix flaws in functionality that officially doesn't
exist. Those issues should be addressed in the scope of service versioning.
Use-cases that you described are interesting and we should try to support
them, but I don't think that we should implement functionality for all
possible cases in single step. I'll think how we can technically support
them in Ignite and I'm open to suggestions from you (and anyone else).
I don't think I understand your concept of ServiceRegistry in the same way
you do. Could you please describe it in more detail?
Thanks.
On Wed, Aug 16, 2017 at 6:06 PM, Sergey Chugunov <se...@gmail.com>
wrote:
> Ilya,
>
> I think the proposed change definitely makes sense.
>
> At the same time I think the scope of the ticket is too broad. It covers at
> least two different aspects of service grid functionality:
>
> - Very specific issue of service upgrade process which is caused by
> current design flaw (although it's not a bug).
> - Very high-level suggestions about improving upgrade process in
> general.
>
>
> I think it is better to separate these things. Lets firstly address item#1
> and then reiterate on #2.
>
> Managing services deployment in distributed system is a non-trivial task
> with a lot of options and different requirements; all changes and
> improvements must be designed thoughtfully.
>
> E.g. for the requirement from the ticket that all services under the same
> name must be of the same version: what if a user wants to test a new
> implementation transparently to the clients of the cluster?
> It would be convenient for that user to be able to redeploy only one
> instance of the service to the newer version (without touching other
> instances) and see if any client reports a problem.
>
> Also I'm familiar with an example when a system with service-like entities
> connected to it supported both upgrades and downgrades: it was possible to
> connect new versions of services to the "parent" system, send some work to
> them but in case of any issues with newer version it was always possible to
> quickly fall back to the previous one known to be stable.
> This use case isn't covered in your ticket at all although I think it is
> kind of obvious feature.
>
> From my point of view Ignite just doesn't have necessary internal
> abstractions to support rich service functionality with managing versions,
> upgrades/downgrades and so on.
> Something like distributed ServiceRegistry concept with managing API to the
> user. We don't have anything like this now.
>
> So I think we should focus on addressing existing issue described in item#1
> and start a new discussion about ways to improve our service grid
> capabilities in a separate thread.
> Item#2 will be addressed automatically as part of that discussion.
>
> Makes sense?
>
> Thanks,
> Sergey.
>
> On Wed, Aug 16, 2017 at 2:22 AM, Denis Magda <dm...@apache.org> wrote:
>
> > Ilya,
> >
> > Every Service Grid user will welcome this feature. Fully for it.
> >
> > Mentioned in the ticket that it has to be documented before the ticket is
> > closed.
> >
> > —
> > Denis
> >
> > > On Aug 15, 2017, at 8:18 AM, Ilya Lantukh <il...@gridgain.com>
> wrote:
> > >
> > > Igniters,
> > >
> > > Our current ServiceGrid implementation lacks several important
> features,
> > > one of which is ability to upgrade Service without downtime.
> > >
> > > I've created ticket to add this feature:
> > > https://issues.apache.org/jira/browse/IGNITE-6069.
> > >
> > > To implement it, the following problems must be solved:
> > > - currently we can store only one BinaryMetadata instance for given
> > > classname - if you change Service class implementation and then try to
> > > deploy it, you might get an exception like
> > > "org.apache.ignite.binary.BinaryObjectException: Binary type has
> > different
> > > field types". It can be solved by making (className, version) unique
> > > metadata identifier. We can use serialVersionUuid as version.
> > > - ServiceProxy must be aware of actual version and know if service is
> > > currently being upgraded. If user tries to execute any method during
> > > upgrade, proxy should implicitly wait until new version is ready. We
> > > already have similar logic in IgniteCacheProxyImpl.
> > > - To effectively and conveniently migrate service state to newer
> version,
> > > we should add method to Service interface that will be executed before
> > > start if older version was present. To keep API compatible, I suggest
> to
> > > introduce interface UpgradableService (extends Service).
> > >
> > > Any critique and suggestions are welcome.
> > >
> > > --
> > > Best regards,
> > > Ilya
> >
> >
>
--
Best regards,
Ilya
Re: Service versioning
Posted by Sergey Chugunov <se...@gmail.com>.
Ilya,
I think the proposed change definitely makes sense.
At the same time I think the scope of the ticket is too broad. It covers at
least two different aspects of service grid functionality:
- Very specific issue of service upgrade process which is caused by
current design flaw (although it's not a bug).
- Very high-level suggestions about improving upgrade process in general.
I think it is better to separate these things. Lets firstly address item#1
and then reiterate on #2.
Managing services deployment in distributed system is a non-trivial task
with a lot of options and different requirements; all changes and
improvements must be designed thoughtfully.
E.g. for the requirement from the ticket that all services under the same
name must be of the same version: what if a user wants to test a new
implementation transparently to the clients of the cluster?
It would be convenient for that user to be able to redeploy only one
instance of the service to the newer version (without touching other
instances) and see if any client reports a problem.
Also I'm familiar with an example when a system with service-like entities
connected to it supported both upgrades and downgrades: it was possible to
connect new versions of services to the "parent" system, send some work to
them but in case of any issues with newer version it was always possible to
quickly fall back to the previous one known to be stable.
This use case isn't covered in your ticket at all although I think it is
kind of obvious feature.
From my point of view Ignite just doesn't have necessary internal
abstractions to support rich service functionality with managing versions,
upgrades/downgrades and so on.
Something like distributed ServiceRegistry concept with managing API to the
user. We don't have anything like this now.
So I think we should focus on addressing existing issue described in item#1
and start a new discussion about ways to improve our service grid
capabilities in a separate thread.
Item#2 will be addressed automatically as part of that discussion.
Makes sense?
Thanks,
Sergey.
On Wed, Aug 16, 2017 at 2:22 AM, Denis Magda <dm...@apache.org> wrote:
> Ilya,
>
> Every Service Grid user will welcome this feature. Fully for it.
>
> Mentioned in the ticket that it has to be documented before the ticket is
> closed.
>
> —
> Denis
>
> > On Aug 15, 2017, at 8:18 AM, Ilya Lantukh <il...@gridgain.com> wrote:
> >
> > Igniters,
> >
> > Our current ServiceGrid implementation lacks several important features,
> > one of which is ability to upgrade Service without downtime.
> >
> > I've created ticket to add this feature:
> > https://issues.apache.org/jira/browse/IGNITE-6069.
> >
> > To implement it, the following problems must be solved:
> > - currently we can store only one BinaryMetadata instance for given
> > classname - if you change Service class implementation and then try to
> > deploy it, you might get an exception like
> > "org.apache.ignite.binary.BinaryObjectException: Binary type has
> different
> > field types". It can be solved by making (className, version) unique
> > metadata identifier. We can use serialVersionUuid as version.
> > - ServiceProxy must be aware of actual version and know if service is
> > currently being upgraded. If user tries to execute any method during
> > upgrade, proxy should implicitly wait until new version is ready. We
> > already have similar logic in IgniteCacheProxyImpl.
> > - To effectively and conveniently migrate service state to newer version,
> > we should add method to Service interface that will be executed before
> > start if older version was present. To keep API compatible, I suggest to
> > introduce interface UpgradableService (extends Service).
> >
> > Any critique and suggestions are welcome.
> >
> > --
> > Best regards,
> > Ilya
>
>
Re: Service versioning
Posted by Denis Magda <dm...@apache.org>.
Ilya,
Every Service Grid user will welcome this feature. Fully for it.
Mentioned in the ticket that it has to be documented before the ticket is closed.
—
Denis
> On Aug 15, 2017, at 8:18 AM, Ilya Lantukh <il...@gridgain.com> wrote:
>
> Igniters,
>
> Our current ServiceGrid implementation lacks several important features,
> one of which is ability to upgrade Service without downtime.
>
> I've created ticket to add this feature:
> https://issues.apache.org/jira/browse/IGNITE-6069.
>
> To implement it, the following problems must be solved:
> - currently we can store only one BinaryMetadata instance for given
> classname - if you change Service class implementation and then try to
> deploy it, you might get an exception like
> "org.apache.ignite.binary.BinaryObjectException: Binary type has different
> field types". It can be solved by making (className, version) unique
> metadata identifier. We can use serialVersionUuid as version.
> - ServiceProxy must be aware of actual version and know if service is
> currently being upgraded. If user tries to execute any method during
> upgrade, proxy should implicitly wait until new version is ready. We
> already have similar logic in IgniteCacheProxyImpl.
> - To effectively and conveniently migrate service state to newer version,
> we should add method to Service interface that will be executed before
> start if older version was present. To keep API compatible, I suggest to
> introduce interface UpgradableService (extends Service).
>
> Any critique and suggestions are welcome.
>
> --
> Best regards,
> Ilya