Hi Andrey, Yes. index is available on eqId of PersonDetail object.
Query says scan for Person cache not the PersonDetail cache. and i think the above Computask executed by only one thread and not by number of threads on number of partitions. Can parallelism achieved here ? Thanks. On 17 February 2017 at 02:32, Andrey Mashenkov <[email protected]> wrote: > 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 >
