Hello! In this case you could use an affinity function which will put all these entries on the same node, but it will mean that you no longer use any distribution benefits.
I don't think it is a good design if you expect local listener to get a tx worth of entries at once. Listener should ideally consider entries in isolation. Regards, -- Ilya Kasnacheev чт, 8 окт. 2020 г. в 19:06, ssansoy <[email protected]>: > Hi, > > We have an app that writes N records to the cluster (REPLICATED) - e.g. > 10,000 records, in one transaction. > > We also have an app that issues a continuous query against the cluster, > listening for updates to this cache. > We'd like the app to receive all 10,000 records in one call into the > localListener. > > We are observing that the continuous query only receives records one at a > time. > I have tried playing around with setPageSize and setTimeInterval, e.g. > pageSize=12,000 timeInterval=10,000 > > E.g. the query waits either 10 seconds for updates to take place, or until > 12,000 updates have occurred. This does seem to be an improvement - but now > rather than 10,000 calls to local listen, we now have 3 calls, e.g. for > quantities 2000, 4500, 3500 for example. These quantities for each callback > are consistently the same upon retries. > Are we observing this behaviour because our cache keys are designated as > "primary" on different nodes of the cluster? So we are effectively getting > 1 > localListen callback per node with the number of entries that are marked as > "primary" on that node? > > This is very problematic for us unfortunately, as we are migrating are apps > to ignite, and a large part of the app processing expects all updates to > arrive in one go so there is a consistent view of the write that has > occurred. Is there anything we can do here to get this behaviour? ideally > without even having to have a timeout and introducing extra delay? > > Thanks. > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
