ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Continuous query deployment
Date Thu, 18 Oct 2018 15:36:41 GMT
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 <dmekhanikov@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message