Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 11 Jul 2017 17:07:00 +0000 (UTC)
From: "James Taylor (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13086276.1499783222000.219259.1499792820273@Atlassian.JIRA>
In-Reply-To: <JIRA.13086276.1499783222000@Atlassian.JIRA>
References: <JIRA.13086276.1499783222000@Atlassian.JIRA> <JIRA.13086276.1499783222000@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4010) Hash Join cache may not be send
 to all regionservers when we have stale HBase meta cache
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 11 Jul 2017 17:13:46 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-4010?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16=
082525#comment-16082525 ]=20

James Taylor commented on PHOENIX-4010:
---------------------------------------

Since presumably this is relatively rare, we could retry the entire query f=
rom PhoenixStatement in the case of a HashCacheNotFoundException. We do tha=
t already for other classes of exceptions such as MetaDataEntityNotFoundExc=
eption.

> Hash Join cache may not be send to all regionservers when we have stale H=
Base meta cache
> -------------------------------------------------------------------------=
---------------
>
>                 Key: PHOENIX-4010
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4010
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Ankit Singhal
>            Assignee: Ankit Singhal
>             Fix For: 4.12.0
>
>         Attachments: PHOENIX-4010.patch
>
>
>  If the region locations changed and our HBase meta cache is not updated =
then we might not be sending hash join cache to all region servers hosting =
the regions.
> ConnectionQueryServicesImpl#getAllTableRegions
> {code}
> boolean reload =3Dfalse;
>         while (true) {
>             try {
>                 // We could surface the package projected HConnectionImpl=
ementation.getNumberOfCachedRegionLocations
>                 // to get the sizing info we need, but this would require=
 a new class in the same package and a cast
>                 // to this implementation class, so it's probably not wor=
th it.
>                 List<HRegionLocation> locations =3D Lists.newArrayList();
>                 byte[] currentKey =3D HConstants.EMPTY_START_ROW;
>                 do {
>                     HRegionLocation regionLocation =3D connection.getRegi=
onLocation(
>                             TableName.valueOf(tableName), currentKey, rel=
oad);
>                     locations.add(regionLocation);
>                     currentKey =3D regionLocation.getRegionInfo().getEndK=
ey();
>                 } while (!Bytes.equals(currentKey, HConstants.EMPTY_END_R=
OW));
>                 return locations;
> {code}
> Skipping duplicate servers in ServerCacheClient#addServerCache
> {code}
> List<HRegionLocation> locations =3D services.getAllTableRegions(cacheUsin=
gTable.getPhysicalName().getBytes());
>             int nRegions =3D locations.size();
>            =20
> .....
>  if ( ! servers.contains(entry) &&=20
>                         keyRanges.intersectRegion(regionStartKey, regionE=
ndKey,
>                                 cacheUsingTable.getIndexType() =3D=3D Ind=
exType.LOCAL)) { =20
>                     // Call RPC once per server
>                     servers.add(entry);
> {code}
> For eg:- Table =E2=80=99T=E2=80=99 has two regions R1 and R2 originally h=
osted on regionserver RS1.=20
> while Phoenix/Hbase connection is still active, R2 is transitioned to RS2=
 ,  but stale meta cache will still give old region locations i.e R1 and R2=
 on RS1 and when we start copying hash table, we copy for R1 and skip R2 as=
 they are hosted on same regionserver. so, the query on a table will fail a=
s it will unable to find hash table cache on RS2 for processing regions R2.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)