ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Mekhanikov <dmekhani...@gmail.com>
Subject Re: Service versioning
Date Tue, 03 Oct 2017 07:48:07 GMT
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 <ilantukh@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 <dmagda@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 <ilantukh@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message