[jira] [Commented] (PHOENIX-2680) stats table timestamp incorrectly used as table timestamp

["James Taylor (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PHOENIX-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143004#comment-15143004 ] 

James Taylor commented on PHOENIX-2680:
---------------------------------------

[~janvanbesien] - This line is necessary as the stats are part of the table metadata and this ensures that the metadata is sent over to the client when the stats are updated. There are a couple of things you can try, though, if this is causing a problem for you:
- set phoenix.stats.useCurrentTime on server side to false. See https://phoenix.apache.org/tuning.html for more info on this parameter:
{code}
An advanced server-side parameter that if true causes the current time on the server-side to be used as the timestamp of rows in the statistics table when background tasks such as compactions or splits occur. If false, then the max timestamp found while traversing the table over which statistics are being collected is used as the timestamp. Unless your client is controlling the timestamps while reading and writing data, this parameter should be left alone. The default value is true.
{code}
- issue your DROP TABLE at the latest timestamp
- disable stats by setting phoenix.stats.guidepost.width to a very large value. This will negatively affect performance, though.

> stats table timestamp incorrectly used as table timestamp
> ---------------------------------------------------------
>
>                 Key: PHOENIX-2680
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2680
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.6.0
>            Reporter: Jan Van Besien
>         Attachments: PHOENIX-2680.patch
>
>
> I think there is a problem introduced by PHOENIX-1390 related to table timestamps.
> We run into a situation where we are unable to drop a table due to a NewerTableAlreadyExistsException. This table was created at a certain timestamp in the past (say 2 years ago) and we try to drop it at a more recent timestamp in the past (say 1 year ago).
> During the drop, the client timestamp (1 year ago) is compared with the table timestamp. The table timestamp should be 2 years ago, but due to this statement on line 856 in MetaDataEndpointImpl:
> {code}
> timeStamp = Math.max(timeStamp, stats.getTimestamp())
> {code}
> the timestamp of the table is set to the timestamp of the stats table, which happens to be something much more recent.
> I think this is wrong?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)