Improve plugins start/stop procedure.

[Vladimir Ozerov]

Igniters,

Ignite allows external parties to add plugins. Currently plugins are
started at the very end of start process, and they are stopped before all
other components.

This is a problem because sometimes we need to stop plugin AFTER all other
components. not BEFORE. E.g. consider a plugin which provides an
environment for custom cache store, and this store has "write-behind"
enabled. In this case we will stop plugin before write-behind store flushed
all data what leads to unexpected behavior.

It seems that we must provide more callbacks so that plugins could be
notified both before and after all other components are started/stopped.

I looked at the code and found that IgnitePluginProcessor is a very good
candidate for this - it starts very early and has access to all plugins.
What if we add the following methods to PluginProvider interface:
onPluginProcessorStart() - called from IgnitePluginProcessor.start();
onPluginProcessorStop() - called from IgnitePluginProcessor.stop().

Vladimir.

[yzhdanov]

Agree with Vladimir. Start/stop order should be flexible.

--Yakov

2015-07-07 10:03 GMT+03:00 Vladimir Ozerov <[hidden email]>:

> Igniters,
>
> Ignite allows external parties to add plugins. Currently plugins are
> started at the very end of start process, and they are stopped before all
> other components.
>
> This is a problem because sometimes we need to stop plugin AFTER all other
> components. not BEFORE. E.g. consider a plugin which provides an
> environment for custom cache store, and this store has "write-behind"
> enabled. In this case we will stop plugin before write-behind store flushed
> all data what leads to unexpected behavior.
>
> It seems that we must provide more callbacks so that plugins could be
> notified both before and after all other components are started/stopped.
>
> I looked at the code and found that IgnitePluginProcessor is a very good
> candidate for this - it starts very early and has access to all plugins.
> What if we add the following methods to PluginProvider interface:
> onPluginProcessorStart() - called from IgnitePluginProcessor.start();
> onPluginProcessorStop() - called from IgnitePluginProcessor.stop().
>
> Vladimir.
>

[Atri Sharma]

+1
On 8 Jul 2015 21:13, "Yakov Zhdanov" <[hidden email]> wrote:

> Agree with Vladimir. Start/stop order should be flexible.
>
> --Yakov
>
> 2015-07-07 10:03 GMT+03:00 Vladimir Ozerov <[hidden email]>:
>
> > Igniters,
> >
> > Ignite allows external parties to add plugins. Currently plugins are
> > started at the very end of start process, and they are stopped before all
> > other components.
> >
> > This is a problem because sometimes we need to stop plugin AFTER all
> other
> > components. not BEFORE. E.g. consider a plugin which provides an
> > environment for custom cache store, and this store has "write-behind"
> > enabled. In this case we will stop plugin before write-behind store
> flushed
> > all data what leads to unexpected behavior.
> >
> > It seems that we must provide more callbacks so that plugins could be
> > notified both before and after all other components are started/stopped.
> >
> > I looked at the code and found that IgnitePluginProcessor is a very good
> > candidate for this - it starts very early and has access to all plugins.
> > What if we add the following methods to PluginProvider interface:
> > onPluginProcessorStart() - called from IgnitePluginProcessor.start();
> > onPluginProcessorStop() - called from IgnitePluginProcessor.stop().
> >
> > Vladimir.
> >
>

[Vladimir Ozerov]

I created the ticket for this:
https://issues.apache.org/jira/browse/IGNITE-1108

Proposed design draft:

1) Start:
PluginProvider.onBeforeStart() - called from IgnitePluginProcessor.start();
PluginProvider.start() - already exists, unchanged;
PluginProvider.onAfterStart() - just rename onIgniteStart() for consistency
with onBeforeStart();

2) Stop procedure is mirrored from start: onBeforeStop(), stop(),
onAfterStop().

3) Introduce PluginProviderAdapter where all methods will be no-op. This
way user plugins extending this class will continue compile in case of
further changes to PluginProvider interfaces provided that method names are
unchanged.

On Wed, Jul 8, 2015 at 7:05 PM, Atri Sharma <[hidden email]> wrote:

> +1
> On 8 Jul 2015 21:13, "Yakov Zhdanov" <[hidden email]> wrote:
>
> > Agree with Vladimir. Start/stop order should be flexible.
> >
> > --Yakov
> >
> > 2015-07-07 10:03 GMT+03:00 Vladimir Ozerov <[hidden email]>:
> >
> > > Igniters,
> > >
> > > Ignite allows external parties to add plugins. Currently plugins are
> > > started at the very end of start process, and they are stopped before
> all
> > > other components.
> > >
> > > This is a problem because sometimes we need to stop plugin AFTER all
> > other
> > > components. not BEFORE. E.g. consider a plugin which provides an
> > > environment for custom cache store, and this store has "write-behind"
> > > enabled. In this case we will stop plugin before write-behind store
> > flushed
> > > all data what leads to unexpected behavior.
> > >
> > > It seems that we must provide more callbacks so that plugins could be
> > > notified both before and after all other components are
> started/stopped.
> > >
> > > I looked at the code and found that IgnitePluginProcessor is a very
> good
> > > candidate for this - it starts very early and has access to all
> plugins.
> > > What if we add the following methods to PluginProvider interface:
> > > onPluginProcessorStart() - called from IgnitePluginProcessor.start();
> > > onPluginProcessorStop() - called from IgnitePluginProcessor.stop().
> > >
> > > Vladimir.
> > >
> >
>

[npordash]

Hi,

This looks like a pretty valuable API enhancement for plugins. Considering the ticket is almost 2 years old is there any chance of this getting done as 2.0 is just around the corner?

-Nick