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

Reply via email to