phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Soldatov (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 Sat, 23 Sep 2017 16:02:00 GMT

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

[~ankit@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)

Mime
View raw message