[
https://issues.apache.org/jira/browse/PHOENIX-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16179890#comment-16179890
]
Sergey Soldatov commented on PHOENIX-4224:
------------------------------------------
[~jamestaylor] That's definitely a regression. Previously client got the
exception that cache has expired when that happen on RS side. Now it falls
into resending logic, but doesn't resend the cache, only recreate scans that do
nothing and creates excessive network traffic as well as a load on region
servers. From the end user perspective that looks like the query fail by
timeout or crash with StackOverflow exception. To figure out that TTL should be
adjusted he/she need to check RS logs.
> 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
> 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)
