Denis, I agree that p2p loading is not the best choice for CQs. Do you know if we've already done anything in that area for the Service Grid? Are we using/going to use Deployment SPI there as well? Either way, I think it would make sense if services and CQs should end up using the same mechanism for dynamic loading.
-Val On Thu, Oct 18, 2018 at 8:36 AM Ilya Kasnacheev <ilya.kasnach...@gmail.com> wrote: > Hello! > > Is it possible to simply disable P2P class loading for remote filter of > continuous queries with autoUnsubscribe = true? > > Regards, > -- > Ilya Kasnacheev > > > чт, 18 окт. 2018 г. в 18:31, Denis Mekhanikov <dmekhani...@gmail.com>: > > > Igniters, > > > > I'm concerned with our continuous query API and deployment procedure. > > > > Continuous queries have remote filters, that can be deployed over peer > > class loading mechanism (this functionality is currently broken though: > > IGNITE-3653 <https://issues.apache.org/jira/browse/IGNITE-3653>, > > IGNITE-9181 > > <https://issues.apache.org/jira/browse/IGNITE-9181>). > > In usual cases P2P class loading makes sense, but problems begin when a > > node, that deployed the CQ, leaves cluster. By default the CQ is > undeployed > > in this case. But ContinuousQuery has *autoUnsubscribe* > > < > > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/query/ContinuousQuery.html#setAutoUnsubscribe-boolean- > > > > > property. If set to true, it lets a continuous query stay in cluster, > when > > initiator leaves. > > So, you may end up in a situation, when a continuous query remote filter > is > > deployed in a cluster, but the node, that the class was loaded from, is > > already gone. > > New nodes won't have where to load the remote filter class from in this > > case. Also existing nodes may have problems, since class loading of > > dependencies of the loaded class happens lazily (and cannot happen > > eagerly), so they also need the initiator node. > > > > The *autoUnsubscribe* property helps to deploy continuous queries, that > > listen to cache updates and react to them in the remote filters. This is > > pretty convenient, since it allows cache updates be processed locally, > > right where updates happen, without sending data over network. Such > > continuous query may not even have a local listener, so initiator node > may > > deploy the query and leave. > > > > *BUT* > > > > - The deployed CQ becomes impossible to undeploy. It stays in the > > cluster till the end of times. > > - This case looks like a miss-use of the remote filters. They should > > *filter*, but not *listen* and *react*. Remote filter should be a > > stateless predicate rather than a clever callback. > > - It causes the problems with P2P class loading, mentioned above. > > > > So, I'd like to see the *autoUnsubscribe *property deprecated and > removed. > > > > This use-case should be covered by a different mechanism, that will allow > > to deploy a listener into a cluster by name. It should support deployment > > SPI <https://apacheignite.readme.io/docs/deployment-spi> instead of peer > > class loading. It may be built on top of continuous queries, but have a > > more suitable API. > > > > What do you think? > > > > Denis > > >
