[
https://issues.apache.org/jira/browse/PHOENIX-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16177860#comment-16177860
]
Sergey Soldatov commented on PHOENIX-4224:
------------------------------------------
[~an...@apache.org] Heh. Actually client may not come out from the recursion
and fail with StackOverflow exception. Even bigger problem is the scans we are
sending. They have filter by key and for the relatively large RHS table the
filter may be hundreds of megabytes and that creates huge (and useless) traffic
over the network. And definitely failure is really slow. For query that is
successfully executed in 5 or less minutes failure after reducing cache ttl
takes over 30 minutes (and actually that was phoenix timeout).
> 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)
