ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Mashenkov <andrey.mashen...@gmail.com>
Subject Re: EntryProcessor for cache
Date Thu, 16 Feb 2017 21:02:39 GMT
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 <anilklce@gmail.com> 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 <valentin.kulichenko@gmail.com>
> 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

Mime
View raw message