Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 26 Sep 2017 02:18:00 +0000 (UTC)
From: "Josh Elser (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13104185.1506062027000.199895.1506392280146@Atlassian.JIRA>
In-Reply-To: <JIRA.13104185.1506062027000@Atlassian.JIRA>
References: <JIRA.13104185.1506062027000@Atlassian.JIRA> <JIRA.13104185.1506062027383@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-4224) Automatic resending cache for
 HashJoin doesn't work when cache has expired on server side
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 26 Sep 2017 02:18:10 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16180098#comment-16180098 ] 

Josh Elser commented on PHOENIX-4224:
-------------------------------------

bq. Playing with different scenarios for large joins I see that in some cases it may be useful and the query would return result instead of failing. In other hands it's more preferable if we fail quickly, letting user know that the cache TTL should be adjusted. 

Oof. That's rough. I'm trying to come up with what the "bandaid" fix would be (to avoid a revert and not block 4.12). Maybe fail quickly with a good error message?

bq. Working on the fix where we keep tracking when the cache has been sent to the servers, so we will be able to separate the cases when it was expired from the cases when it was never sent ( due the region movement across the region servers). 

You close to this kind of fix? Should 4.12 wait for it? (half a question for Sergey, half for James)

> Automatic resending cache for HashJoin doesn't work when cache has expired on server side 
> ------------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-4224
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4224
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.12.0
>            Reporter: Sergey Soldatov
>            Assignee: Sergey Soldatov
>            Priority: Blocker
>             Fix For: 4.12.0
>
>
> The problem occurs when the cache has expired on server side and client want to resend it. This problem has been introduced in PHOENIX-4010. Actual result in this case is that client doesn't send the cache because of the following check:
> {noformat}
> 			if (cache.addServer(tableRegionLocation) ... )) {
> 				success = addServerCache(table, startkeyOfRegion, pTable, cacheId, cache.getCachePtr(), cacheFactory, txState);
> 			}
> {noformat}
> Since the region location hasn't been changed, we actually don't send cache again, but produce new scanner which will fail with the same error and client will fall to recursion. 


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