Overriding GridQueryProcessor

classic Classic list List threaded Threaded
3 messages Options
Hemambara Hemambara
Reply | Threaded
Open this post in threaded view
|

Overriding GridQueryProcessor

This post was updated on .
Hi

In order to fix the issue that we are discussing @
http://apache-ignite-users.70518.x6.nabble.com/Issue-with-adding-nested-index-dynamically-tc29571.html

I found a workaround to override GridQueryProcessor and use
CustomGridQueryProcessor which extends GridQueryProcessor and override few
functionality. To do that I am getting hold of KernalContext and stopping
existing GridQueryProcessor that has been already started during startup and
adding my CustomGridQueryProcessor. But my worry is when Ignite instance is
created it is open for discovery, traffic will be started and existing
GridQueryProcessor might get traffic. But if stop and start meanwhile if we
get any message, I might loose it.

My question is :
1) Is there any other better way to override GridQueryProcessor ? (or)
2) Is there any way we can stop traffic in local node for that moment until
new CustomGridQueryProcessor has been started and restart it ?


List<Ignite> igniteLocalGrids = Ignition.allGrids();
        for(Ignite igniteLocalGrid : igniteLocalGrids) {
            LOGGER.info("Configuring {} ",CustomGridQueryProcessor.class.getName(), igniteLocalGrid.name());
            GridKernalContextImpl kernalContext = ((GridKernalContextImpl)((IgniteKernal)igniteLocalGrid).context());

            kernalContext.query().stop(true);
            kernalContext.query().onKernalStop(true);
            GridCacheProcessor gridCacheProcessor = kernalContext.cache();
            for (final IgniteInternalCache cache : gridCacheProcessor.caches()) {
                GridCacheContext cctx = cache.context();
                kernalContext.query().onCacheStop(cctx, true);
            }


            CustomGridQueryProcessor processor = new CustomGridQueryProcessor(kernalContext);
            processor.start();
            for (final IgniteInternalCache cache : gridCacheProcessor.caches()) {
                GridCacheContext cctx = cache.context();
                DynamicCacheDescriptor desc = gridCacheProcessor.cacheDescriptor(cctx.name());
                processor.onCacheStart(cctx, desc.schema());
            }

            processor.onCacheKernalStart();
            kernalContext.add(processor, true);
            LOGGER.info("Configured {} ",CustomGridQueryProcessor.class.getName(), igniteLocalGrid.name());
        }




--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
ilya.kasnacheev ilya.kasnacheev
Reply | Threaded
Open this post in threaded view
|

Re: Overriding GridQueryProcessor

Hello!

GridQueryProcessor is an internal class (residing in internal package) so it is not supposed to be user serviceable. It may work for you, but we can't support a configuration like this one.

Regards,
--
Ilya Kasnacheev


ср, 20 нояб. 2019 г. в 18:22, Hemambara <[hidden email]>:
Hi

In order to fix the issue that we are discussing @
http://apache-ignite-users.70518.x6.nabble.com/Issue-with-adding-nested-index-dynamically-tc29571.html

I found a workaround to override GridQueryProcessor and use
CustomGridQueryProcessor which extends GridQueryProcessor and override few
functionality. To do that I am getting hold of KernalContext and stopping
existing GridQueryProcessor that has been already started during startup and
adding my CustomGridQueryProcessor. But my worry is when Ignite instance is
created it is open for discovery, traffic will be started and existing
GridQueryProcessor might get traffic. But if stop and start meanwhile if we
get any message, I might loose it.

My question is :
1) Is there any other better way to override GridQueryProcessor ? (or)
2) Is there any way we can stop traffic in local node for that moment until
new CustomGridQueryProcessor has been started and restart it ?


List<Ignite> igniteLocalGrids = Ignition.allGrids();
        for(Ignite igniteLocalGrid : igniteLocalGrids) {
            GridKernalContextImpl kernalContext =
((GridKernalContextImpl)((IgniteKernal)igniteLocalGrid).context());
            kernalContext.query().stop(true);
            CustomGridQueryProcessor processor = new
CustomGridQueryProcessor(kernalContext);
            processor.start();

            GridCacheProcessor gridCacheProcessor = kernalContext.cache();
            for (final IgniteInternalCache cache :
gridCacheProcessor.caches()) {
                GridCacheContext cctx = cache.context();
                DynamicCacheDescriptor desc =
gridCacheProcessor.cacheDescriptor(cctx.name());
                processor.onCacheStart0(cctx, desc.schema());
            }

            processor.onCacheKernalStart();
            kernalContext.add(processor, true);
        }






--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
akurbanov akurbanov
Reply | Threaded
Open this post in threaded view
|

Re: Overriding GridQueryProcessor

Hi,

Unfortunately the GridQueryProcessor was not designed to be pluggable, but
it seems to me that among the best option that you might have is to
implement PluginProcessor and IgnitePlugin and do it there. Another option
is to implement LifecycleBean and rely on AFTER_NODE_START event that is
processed synchronously right before the end of IgniteKernal.start().

Here a couple of references to classes that might be useful for
understanding the plugin approach in case you will go this way:

https://github.com/apache/ignite/blob/master/modules/direct-io/src/main/java/org/apache/ignite/internal/processors/cache/persistence/file/LinuxNativeIoPluginProvider.java

https://github.com/apache/ignite/blob/master/modules/direct-io/src/main/java/org/apache/ignite/internal/processors/cache/persistence/file/LinuxNativeIoPlugin.java

Lifecycle bean is pretty straightforward to use, and even has an example:

https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/misc/lifecycle/LifecycleExample.java

But anyway, since query processor was not designed this way, I would do a
proper test to see if this may work.

Best regards,
Anton



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/