Hello, Denis. Thank you for this discussion. I have a few notes:
1. Is it possible to change the list of deployed resources in runtime via
built-in DeploymentSPI implementations?
Can I add or remove jar to(from) class-path without node(cluster) restart?
2. Can we update service dependencies via DeploymentSPI? commons-lang, log4j or
any other common library?
3. User has to execute explicit Ignite API calls(undeploy(), deploy()) to renew
service implementation. Is it correct?
I think we should develop some watcher, that will be watch for a resource
change and redeploy services automatically.
4. DeploymentSPI is *node-wide* configuration. This means we change classpath
for all services with this SPI.
I think this is a huge limitation of the SPI.
We should provide an ability to configure service-wide classpath to our users
as quickly as possible.
It is a common feature in modern service, task executor engines.
I think the perfect world scenario would be following:
1. Start a client node or connect to a cluster with thin client.
2. Configure service classpath with some new Ignite API.
The only requirement for classes - they should be available locally(on
client node or thin client host).
3. User deploy the service with some Ignite API.
4. After depoyment completes successfully client node can be stopped.
All required resource to run a service should be safely stored in
cluster and deployed to any new node.
5. I think we should develop examples for a DeploymentSPI usage.
As far as I can see, there is no such examples in our codebase for now.
Is it correct? If so, I will create a ticket to create such examples.
В Вт, 05/02/2019 в 01:08 +0300, Vyacheslav Daradur пишет:
> Denis, thank you for driving of Service Grid's development!
>
> Sounds like a good plan. Does it mean that a user will have to
> register a classloader for service's class explicitly in case of using
> the feature?
>
> On Mon, Feb 4, 2019 at 4:38 PM Denis Mekhanikov <dmekhani...@gmail.com> wrote:
> >
> > Igniters,
> >
> > I'd like to start a dedicated thread for discussion of the design of
> > services hot redeployment. The previous service design discussion can be
> > found in the following thread: [1]
> >
> > Currently adding a new service or implementation change of an existing one
> > requires restarting the hosting nodes. Service instances are deserialized
> > using an application class loader, so the service class should be present
> > on the classpath of the node. The only way to change the set of available
> > classes is to restart the node. Potentially the whole cluster restart can
> > be required. This is a major drawback in the current design. This problem
> > should be addressed first.
> >
> > At the same time this problem can be resolved by relatively simple code
> > changes. We need to change the way services are deserialized, and use a
> > mechanism, that allows dynamic class changes. Deployment SPI [2] seems to
> > be suitable for this. We can apply the same approach, which is used for
> > tasks, so services will become dynamically modifiable.
> >
> > With this approach user will still need to perform a cancel-deploy routine
> > for the changed service. But even with that the usability improvement will
> > be huge. We'll think about service availability improvement after the first
> > part is finished.
> >
> > Thoughts?
> >
> > [1]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Service-versioning-td20858.html
> > [2] https://apacheignite.readme.io/docs/deployment-spi#deploymentspi
> >
> > Denis
>
>
>
> --
> Best Regards, Vyacheslav D.
signature.asc
Description: This is a digitally signed message part
