phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4224) Automatic resending cache for HashJoin doesn't work when cache has expired on server side
Date Tue, 26 Sep 2017 02:18:00 GMT

    [ 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)

Mime
View raw message