ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: Service grid redesign
Date Mon, 09 Apr 2018 17:50:00 GMT
Denis,

I would encourage us to persist a service configuration in the meta store
and have this capability enabled by default. That's essential for services
started dynamically. Moreover, we support similar behavior for caches,
indexes, and other DDL changes happened at runtime.

--
Denis

On Mon, Apr 9, 2018 at 9:34 AM, Denis Mekhanikov <dmekhanikov@gmail.com>
wrote:

> Another question, that I would like to discuss is whether services should
> be preserved on cluster restarts.
>
> Currently it depends on persistence configuration. If persistence for any
> data region is enabled, then services will be persisted as well. This is a
> pretty strange way of configuring this behaviour.
> I'm not sure, if anybody relies on this functionality right now. Should we
> support it at all? If yes, should we make it configurable?
>
> Denis
>
> пн, 9 апр. 2018 г. в 19:27, Denis Mekhanikov <dmekhanikov@gmail.com>:
>
> > Val,
> >
> > Sounds reasonable. I just think, that user should have some way to know,
> > that new version of a service class was deployed.
> > One way to do it is to listen to *EVT_CLASS_DEPLOYED. *I'm not sure,
> > whether it is triggered on class redeployment, though. If not, then
> another
> > event type should be added.
> >
> > I don't think, that a lot of people will implement their own
> > *DeploymentSpi*-s, so we should make work with *UriDeploymentSpi* as
> > comfortable as possible.
> >
> > Denis
> >
> > пт, 6 апр. 2018 г. в 23:40, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com>:
> >
> >> Yes, the class deployment itself has to be explicit. I.e., there has to
> be
> >> a manual step where user updates the class, and the exact step required
> >> would depend on DeploymentSpi implementation. But then Ignite takes care
> >> of
> >> everything else - service redeployment and restart is automatic.
> >>
> >> Dmitriy Pavlov, all this is going to be disabled if DeploymentSpi is not
> >> configured. In this case service class definitions have to be deployed
> on
> >> local classpath and can't be updated in runtime. Just like it works
> right
> >> now.
> >>
> >> -Val
> >>
> >> On Fri, Apr 6, 2018 at 10:20 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org
> >> >
> >> wrote:
> >>
> >> > On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov <dpavlov.spb@gmail.com>
> >> > wrote:
> >> >
> >> > > Hi Igniters,
> >> > >
> >> > > I like automatic redeploy which can be disabled by config if user
> >> wants
> >> > to
> >> > > control this process. What do you think?
> >> > >
> >> >
> >> > I do not think we should have anything automatic when it comes to
> >> > deployment, everything should be explicit. However, if we use the
> >> > deployment SPI, then a user should be able to do "hot" redeploy,
> where a
> >> > new service will be deployed if the user drops an updated jar.
> >> >
> >> > We should not create anything new here. Ignite already has a
> deployment
> >> SPI
> >> > and it already works in a certain way. Let's not change it.
> >> >
> >> > D.
> >> >
> >>
> >
>

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