Hi Anil, 1. Seems, some node enter to topology, but cannot finish partition map exchange operations due to long running transtaction or smth holds lock on a partition.
2. /* PERSON_CACHE.PERSON.__SCAN_ */ says that no indices is used for this query and sull scan will be performed.Do you have an index on PersonDetail.eqId field? On Thu, Feb 16, 2017 at 6:50 PM, Anil <[email protected]> wrote: > Hi Val, > > I have created ComputeTask which updates which scans the local cache and > updates its information to child records in another cache. Both caches are > collocated so that parent and child records fall under node and partition. > > 1. I see following warning in the logs when compute task is running - > > GridCachePartitionExchangeManager:480 - Failed to wait for partition map > exchange [topVer=AffinityTopologyVersion [topVer=6, minorTopVer=0], > node=c7a3957b-a3d0-4923-8e5d-e95430c7e66e]. Dumping pending objects that > might be the cause: > > Should I worry about this warning ? what could be the reason for this > warning. > > 2. > > QueryCursor<Entry<String, Person>> cursor = cache.query(new > SqlQuery<String, Person>(Person.class, "select * from Person").*setLocal(* > *true**)*); > > > > for (Entry<String, Person> row : cursor) { > > String eqId = row.getValue().getEqId(); //(String) row.get(0); > > QueryCursor<Entry<AffinityKey<String>, PersonDetail>> dCursor = > > detailsCache.query(new > SqlQuery<AffinityKey<String>, PersonDetail>(PersonDetail.class, > > > > "select * from DETAIL_CACHE.PersonDetail where eqId = ?"). > *setLocal(true)*.setArgs(eqId)); > > for (Entry<AffinityKey<String>, PersonDetail> d : dCursor) { > > // add person info to person detail and add to person > detail data streamer. > > } > > > } > > > I see (in logs) that query is taking long time - > > > Query execution is too long [time=23309 ms, sql='SELECT > "PERSON_CACHE".Person._key, "PERSON_CACHE".PERSON._val from Person', plan= > > SELECT > > PERSON_CACHE.PERSON._KEY, > > PERSON_CACHE.PERSON._VAL > > FROM PERSON_CACHE.PERSON > > /* PERSON_CACHE.PERSON.__SCAN_ */ > > , parameters=[]] > > any issues with the above approach ? thanks. > > > Thanks. > > > On 11 February 2017 at 04:18, vkulichenko <[email protected]> > wrote: > >> Looks ok except that the first query should also be local I guess. Also >> note >> that you used split adapter, so didn't actually map the jobs to nodes, >> leaving this to Ignite. This means that there is a chance some nodes will >> get more than one job, and some none of the jobs. Round robin balancing is >> used by default, so this should not happen, at least on stable topology, >> but >> theoretically there is no guarantee. Use map method instead to manually >> map >> jobs to nodes, or just use broadcast() method. >> >> Jobs are executed in parallel in the public thread pool. >> >> -Val >> >> >> >> -- >> View this message in context: http://apache-ignite-users.705 >> 18.x6.nabble.com/EntryProcessor-for-cache-tp10432p10559.html >> Sent from the Apache Ignite Users mailing list archive at Nabble.com. >> > > -- Best regards, Andrey V. Mashenkov
