Denis, EVT_CLASS_DEPLOYED should be fired every time a class is deployed or redeployed. If this doesn't happen in some cases, I believe this would be a bug. I don't think we need to add any new events.
-Val On Mon, Apr 9, 2018 at 10:50 AM, Denis Magda <dma...@apache.org> wrote: > 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 <dmekhani...@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 <dmekhani...@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.kuliche...@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 < > > dsetrak...@apache.org > > >> > > > >> wrote: > > >> > > >> > On Fri, Apr 6, 2018 at 9:13 AM, Dmitry Pavlov < > dpavlov....@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. > > >> > > > >> > > > > > >
