Thank you very much Michael! From: Michael Cherkasov <michael.cherka...@gmail.com> Reply-To: "user@ignite.apache.org" <user@ignite.apache.org> Date: Thursday, September 10, 2020 at 9:00 PM To: "user@ignite.apache.org" <user@ignite.apache.org> Subject: Re: Ignite 2.8.1 ContinuousQuery: ClassNotFoundException on a client node
Hello Ivan, Right now CQ deployed remote filter on all nodes, even on client nodes that don't store any data and this doesn't make sense, I think Ignite should not deploy it at all on non-affinity nodes. I filed a ticket for this: https://issues.apache.org/jira/browse/IGNITE-13432<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_IGNITE-2D13432&d=DwMFaQ&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=MLjjSCo7nXvBTJrtds9MJK6ipFRCy7UroWewgejPc38&m=TqmR5JObkqnePGWK6fOW6ymOChiV6OEUq7Ka7kbXwqY&s=-UnmRXZhqLaUOq44HsUK2E334fqXZexn9MVaa-YQE0s&e=> Regarding the warning, the CQ is already deployed, but if you will try to deploy a new one while the client is online it will fail, just make sure that you deploy all CQ while clients are offline or put a remote filter to client nodes too, btw peer class loading can help with this. Thanks, Mike. чт, 10 сент. 2020 г. в 10:14, <ivan.fedoren...@tdameritrade.com<mailto:ivan.fedoren...@tdameritrade.com>>: Hi everyone! I am getting ClassNotFoundException on a client node when a server node registers a new ContinuousQuery with a remote filter class that is not in the classpath of a client node. Could someone please clarify if this is the expected behavior and all the client nodes must have all remove filters in their classpath? I wonder if it is correct that client nodes are participating in continuous query execution at all? According to the ticket (https://issues.apache.org/jira/browse/IGNITE-11907<https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.apache.org_jira_browse_IGNITE-2D11907&d=DwMFaQ&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=MLjjSCo7nXvBTJrtds9MJK6ipFRCy7UroWewgejPc38&m=TqmR5JObkqnePGWK6fOW6ymOChiV6OEUq7Ka7kbXwqY&s=aJT_lLmC3QIwoJGbLRfbGhpuBfOcml5Aje4oBPyYobA&e=>) it looks like a client node can even break some functionality on a server node that tries to initialize a new continuous query. At the same time I see the following message when a new client node enters the topology: 55<https://tda-tech.slack.com/archives/DMN0052E8/p1599756934075000<https://urldefense.proofpoint.com/v2/url?u=https-3A__tda-2Dtech.slack.com_archives_DMN0052E8_p1599756934075000&d=DwMFaQ&c=nulvIAQnC0yOOjC0e0NVa8TOcyq9jNhjZ156R-JJU10&r=MLjjSCo7nXvBTJrtds9MJK6ipFRCy7UroWewgejPc38&m=TqmR5JObkqnePGWK6fOW6ymOChiV6OEUq7Ka7kbXwqY&s=RWXwUebGynRvbVoY2QU4C_xqDe1M7PZ3Tm7xjxT4oz8&e=>> 10.09.20 18:55:00.407 [tcp-client-disco-msg-worker-#4] WARN tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on client node. Can be ignored. 10.09.20 18:55:00.410 [tcp-client-disco-msg-worker-#4] WARN tcp.TcpDiscoverySpi-Failed to unmarshal continuous query remote filter on client node. Can be ignored. So in case when a new client node joins all the running queries continue to work as expected (at least it is written in the log). Best regards, Ivan Fedorenkov
