Jin, It's not a bug. All nodes, that will be executing the initial query, should have metadata of the query class. When you register an initial query or a remote filter for a CQ, their objects should be sent to remote nodes, so metadata update is triggered.
It's possible, that anonymous classes, that you are using as remote filter and initial query, cause the whole outer class to be serialized. Try making them static or external classes. It will eliminate possibility, that more data is serialized, than needed. Denis вт, 28 нояб. 2017 г. в 18:41, guojin0...@126.com <guojin0...@126.com>: > denis, thanks for your reply. > > actually in my case, there is.no data in cache when registering CQ. the > log shows that meta data thing will take serveral mins. > currently i disabled the initial query and remotefilter. > my concern is why those meta data exchange happys? as you can see, my > initial query and remotefilter just do a string compare and dont need any > extra class help, all my logic is in local listener which just runs > locally. > i dont see necessary for that exchange in this case. is that a bug? > br, > jin > ---Original--- > *From:* "Denis Mekhanikov"<dmekhani...@gmail.com> > *Date:* 2017/11/28 16:18:03 > *To:* "user"<user@ignite.apache.org>; > *Subject:* Re: Register Contentious query quit slow > > Jin, > > Regarding the problem with initial query: it's not binary metadata update, > what causes the slow-down, but processing the data. > Binary metadata update is done by just sending a few messages across the > ring, it's not a big deal, you shouldn't care too much about it. > You just have a lot of data, and all of it is processed by initial query. > That's why you get such performance impact. > > Metadata does not contain Java classes, it's some internal information > about structure of objects, that are stored in cache. > So, if you put data of some type for the first time, it will cause > metadata update messages to be sent across the ring. > > I'm not sure, that I understand your goal completely, but you can take a > look at a node filter > <https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/CacheConfiguration.html#setNodeFilter(org.apache.ignite.lang.IgnitePredicate)> > cache configuration parameter, looks like it could help. > > As I already said, you shouldn't build a cluster on nodes, that are > connected with an unreliable network. It will lead to stability issues like > segmentation or split-brain. > It will also lead to slow work of discovery SPI, because nodes has a ring > topology, and they may be connected in interleaving order (1st DC, then > 2nd, then 1st, then 2nd again, etc). > > If you want to connect multiple DCs, you can consider using proprietary > solutions for datacenter replication. Here is one of the options: > https://www.gridgain.com/products/software/enterprise-edition/data-center-replication > You can also implement it yourself, since Ignite has pluggable modules > support. > > Denis > > вт, 28 нояб. 2017 г. в 3:58, gunman524 <guojin0...@126.com>: > >> Denis, >> >> For this cross region case, I've some thought to share and please help >> verify whether they are already here. >> >> 1. Two DC, A ---corss region--- B >> 2. A have several ignite node, A1,A2,A3 .... and B have several ignite >> node, B1,B2,B3 ..., there are in a same cluster >> 3. In ingite, A1,A2, A3 can belongs to same group, says A' and B1,B2,B3 >> can >> be B' >> >> So, can Ignite do this way >> 1. For data deployed in A' and B' by REPLICATED mode and within A' using >> PARTITION mode >> 2. The Continuous Query can only register in A' >> >> In this way: >> 1. As within A', all node in same DC, every action can be performed fast, >> 2 .meanwhile, as A' B' have some data, so we should not missing any event >> 3. As data in A',B' deployed in PARTITION mode, each node do not need to >> hold a hug memory. >> >> Thanks, >> Jin >> >> >> >> >> >> -- >> Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >> >
