[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17791269#comment-17791269
]
Rajeshbabu Chintaguntla commented on OMID-240:
----------------------------------------------
bq.Can you confirm that the failing tests have omid.server.side.filter enabled ?
While creating transactional table object in the phoenix we are enabling
serverSideFilter by default even though in omid it's false by default so we can
control it through the configuration.
{noformat}
public OmidTransactionTable(PhoenixTransactionContext ctx, Table hTable,
boolean isConflictFree, boolean addShadowCells) throws SQLException {
...
tTable = new TTable(hTable, true, isConflictFree);
....
this.tx = omidTransactionContext.getTransaction();
}
{noformat}
bq.At the very least, we should print some strongly worded error messages in
the coprocessor startup code when an invalid combination is set.
To identify the combination is invalid during coprocessor startup we need to do
any of the following 3 steps looks like good amount of work might be required
to these changes will take up as a new JIRA.
1. We need pass the TSO server configurations to each region server which will
operational burden as the cluster managers need to change the configurations
and restart if anything required that's by currently by default creating the
HBase commit table client and trying to check the commit timestamp from the
client.
2. We need fetch the information from TSO server which might need to add RPC
call and implementation of it to check which commit table information has
configured at server based on the server filter configuration.
3. While starting the TSO server needs to verify the combinations properly
seems like cannot conclude the right set properly without looking proper HBase
configurations like server side filters etc..
bq.We should also print an error message if HA is configured, but any InMemory
Module is used.
Yes we can do that.
bq.We should document these (for that, we would need fix the Omid web page), at
the very least as a release note.
We can add the release notes and update the documentation what configurations
needs to be used in which scenario.
bq.Ideally, we would run all tests with both InMemory modules and server-side
filter off, and HBase modules and server-server-side filtering is enabled (not
in this ticket's scope)
Will raise a JIRA for this and work on it later.
bq.Have you looked at the performance implications ?
Even with server side filtering commit timestamps are getting cached mostly
only one call to HBase commit table may happen.
bq.How do hbase + server side filtering and in-memory and no server-side
filtering compare ?
Trying to collect some basic details regarding this. Will get back to you.
bq.I would imagine that server-side filtering mostly makes a difference for hot
rows, like application level locks and counters, and for slowly changing keys
it doesn't do that much.
Yes better not to use server-side filtering if the changes happen rarely.
bq.Actually, I think we could just refuse to start TSO server for that invalid
combination of in-memory modules and HA.
Will check and work as part of another JIRA.
bq.All in all, changing the default looks like the safe choice, but we should
document this issue thoroughly.
Yes I have made a patch just doing some testing will upload the patch tomorrow.
> Transactional visibility is broken
> ----------------------------------
>
> Key: OMID-240
> URL: https://issues.apache.org/jira/browse/OMID-240
> Project: Phoenix Omid
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Lars Hofhansl
> Assignee: Rajeshbabu Chintaguntla
> Priority: Critical
> Attachments: hbase-omid-client-config.yml,
> omid-server-configuration.yml
>
>
> Client I:
> {code:java}
> > create table test(x float primary key, y float) DISABLE_WAL=true,
> TRANSACTIONAL=true;
> No rows affected (1.872 seconds)
> > !autocommit off
> Autocommit status: false
> > upsert into test values(rand(), rand());
> 1 row affected (0.018 seconds)
> > upsert into test select rand(), rand() from test;
> -- 18-20x
> > !commit{code}
>
> Client II:
> {code:java}
> -- repeat quickly after the commit on client I
> > select count(*) from test;
> +----------+
> | COUNT(1) |
> +----------+
> | 0 |
> +----------+
> 1 row selected (1.408 seconds)
> > select count(*) from test;
> +----------+
> | COUNT(1) |
> +----------+
> | 259884 |
> +----------+
> 1 row selected (2.959 seconds)
> > select count(*) from test;
> +----------+
> | COUNT(1) |
> +----------+
> | 260145 |
> +----------+
> 1 row selected (4.274 seconds)
> > select count(*) from test;
> +----------+
> | COUNT(1) |
> +----------+
> | 260148 |
> +----------+
> 1 row selected (5.563 seconds)
> > select count(*) from test;
> +----------+
> | COUNT(1) |
> +----------+
> | 260148 |
> +----------+
> 1 row selected (5.573 seconds){code}
> The second client should either show 0 or 260148. But no other value!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
