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
