[
https://issues.apache.org/jira/browse/PHOENIX-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16345672#comment-16345672
]
James Taylor commented on PHOENIX-4130:
---------------------------------------
Need a couple more changes to MetaDataProtocol :
- add constant for MIN_SYSTEM_TABLE_TIMESTAMP_4_14_0 =
MIN_SYSTEM_TABLE_TIMESTAMP_4_11_0
- set MIN_SYSTEM_TABLE_TIMESTAMP = MIN_SYSTEM_TABLE_TIMESTAMP_4_14_0
- add entry in TIMESTAMP_VERSION_MAP for "4.14.x"
Though MIN_SYSTEM_TABLE_TIMESTAMP_4_14_0 will be the same as
MIN_SYSTEM_TABLE_TIMESTAMP_4_11_0, it might diverge if we add any columns to
system catalog. See this commit for an example:
https://github.com/apache/phoenix/commit/79eff5f89adb2c05024272203eebf0504f82ee3d#diff-32c0a7b3afe8b5b9cff24784b07433f6
{code}
public static final long MIN_SYSTEM_TABLE_TIMESTAMP_4_13_0 =
MIN_SYSTEM_TABLE_TIMESTAMP_4_11_0;
// MIN_SYSTEM_TABLE_TIMESTAMP needs to be set to the max of all the
MIN_SYSTEM_TABLE_TIMESTAMP_* constants
public static final long MIN_SYSTEM_TABLE_TIMESTAMP =
MIN_SYSTEM_TABLE_TIMESTAMP_4_13_0;
// ALWAYS update this map whenever rolling out a new release (major, minor
or patch release).
// Key is the SYSTEM.CATALOG timestamp for the version and value is the
version string.
private static final NavigableMap<Long, String> TIMESTAMP_VERSION_MAP = new
TreeMap<>();
static {
TIMESTAMP_VERSION_MAP.put(MIN_SYSTEM_TABLE_MIGRATION_TIMESTAMP,
MIGRATION_IN_PROGRESS);
TIMESTAMP_VERSION_MAP.put(MIN_SYSTEM_TABLE_TIMESTAMP_4_1_0, "4.1.x");
{code}
> Avoid server retries for mutable indexes
> ----------------------------------------
>
> Key: PHOENIX-4130
> URL: https://issues.apache.org/jira/browse/PHOENIX-4130
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Lars Hofhansl
> Assignee: Vincent Poon
> Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4130.v1.master.patch,
> PHOENIX-4130.v2.master.patch, PHOENIX-4130.v3.master.patch,
> PHOENIX-4130.v4.master.patch, PHOENIX-4130.v5.master.patch,
> PHOENIX-4130.v6.master.patch, PHOENIX-4130.v7.master.patch,
> PHOENIX-4130.v8.master.patch
>
>
> Had some discussions with [~jamestaylor], [~samarthjain], and [~vincentpoon],
> during which I suggested that we can possibly eliminate retry loops happening
> at the server that cause the handler threads to be stuck potentially for
> quite a while (at least multiple seconds to ride over common scenarios like
> splits).
> Instead we can do the retries at the Phoenix client that.
> So:
> # The index updates are not retried on the server. (retries = 0)
> # A failed index update would set the failed index timestamp but leave the
> index enabled.
> # Now the handler thread is done, it throws an appropriate exception back to
> the client.
> # The Phoenix client can now retry. When those retries fail the index is
> disabled (if the policy dictates that) and throw the exception back to its
> caller.
> So no more waiting is needed on the server, handler threads are freed
> immediately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
