Re: Continuous query deployment

Val, I'm working on this issue right now. I don't see an ultimate problem here. The discovery data can be deserialized using a system class loader. Serialized representation is stored in *CacheContinuousQueryDeployableObject.* The actual deserialization happens later, when any class loader can be

Re: Continuous query deployment

Guys, Correct me if I am wrong, but to my knowledge peer class loading doesn't *really* work for CQs regardless of autoUnsubscribe flag. The issue is that filter is distributed via discovery messages when new node joins, but discovery uses JDK marshaller that is not aware of p2p loading. So classe

Re: Continuous query deployment

Ilya, Disabling P2P class loading for CQ with *autoUnsubscribe=false* is a minimum, that should be done. But it will only solves one of the existing problems. It's still unclear, how to undeploy such queries. Continuous queries with *autoUnsubscribe=true* have different semantic with the ones with

Re: Continuous query deployment

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 f

Re: Continuous query deployment

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 : > Igniters, > > I'm concerned with our continuous query API and deployment procedure. > >

Continuous query deployment

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 , IGNITE-91