[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789943#comment-17789943
]
Istvan Toth commented on OMID-240:
----------------------------------
Thank you for detailed explanation, [~rajeshbabu].
I looked into this a bit.
According to https://omid.incubator.apache.org/quickstart.html
Server-side filtering is an optional feature, so having the In-memory as
default is not technically wrong if omid.server.side.filter is disabled (which
is the default).
Can you confirm that the failing tests have omid.server.side.filter enabled ?
Having said that, this is a huge gothca for users, which doesn't seem oto be
documented.
At the very least, we should print some strongly worded error messages in the
coprocessor startup code when an invalid combination is set.
We should also print an error message if HA is configured, but any InMemory
Module is used.
We should document these (for that, we would need fix the Omid web page), at
the very least as a release note.
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)
Have you looked at the performance implications ?
How do hbase + server side filtering and in-memory and no server-side filtering
compare ?
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.
All in all, changing the default looks like the safe choice, but we should
document this issue thoroughly.
> 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)
