[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791456#comment-17791456
]
Istvan Toth edited comment on OMID-240 at 11/30/23 4:56 AM:
In the short term, I think it's OK to say that the only supported config is
hbase commit storage module + server side filtering.
-IUC this is shomething that we could check both at coprocessor startup time
and in the client independently.-
Phoenix-server contains the required code anyway.
was (Author: stoty):
In the short term, I think it's OK to say that the only supported config is
hbase commit storage module + server side filtering.
IUC this is shomething that we could check both at coprocessor startup time and
in the client independently.
Phoenix-server contains the required code anyway.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791445#comment-17791445
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/30/23 4:43 AM:
[~stoty]
All kinds of select queries are failing without server side filtering with both
inmemory commit storage module as well as hbase commit storage module. So would
be better to stick to server side filtering and hbase commit storage table.
{noformat}
0: jdbc:phoenix:> select count(*) from test;
Error: java.lang.IllegalArgumentException: Timestamp cannot be negative.
minStamp:9223372036854775807, maxStamp:-9223372036854775808
(state=08000,code=101)
org.apache.phoenix.exception.PhoenixIOException:
java.lang.IllegalArgumentException: Timestamp cannot be negative.
minStamp:9223372036854775807, maxStamp:-9223372036854775808
at
org.apache.phoenix.util.ServerUtil.parseServerException(ServerUtil.java:138)
at
org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:1379)
at
org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:1318)
at
org.apache.phoenix.iterate.ConcatResultIterator.getIterators(ConcatResultIterator.java:52)
at
org.apache.phoenix.iterate.ConcatResultIterator.currentIterator(ConcatResultIterator.java:107)
at
org.apache.phoenix.iterate.ConcatResultIterator.next(ConcatResultIterator.java:127)
at
org.apache.phoenix.iterate.UngroupedAggregatingResultIterator.next(UngroupedAggregatingResultIterator.java:39)
at
org.apache.phoenix.jdbc.PhoenixResultSet.next(PhoenixResultSet.java:841)
at sqlline.BufferedRows.nextList(BufferedRows.java:109)
at sqlline.BufferedRows.(BufferedRows.java:52)
at sqlline.SqlLine.print(SqlLine.java:1672)
at sqlline.Commands.executeSingleQuery(Commands.java:1063)
at sqlline.Commands.execute(Commands.java:1003)
at sqlline.Commands.sql(Commands.java:967)
at sqlline.SqlLine.dispatch(SqlLine.java:734)
at sqlline.SqlLine.begin(SqlLine.java:541)
at sqlline.SqlLine.start(SqlLine.java:267)
at sqlline.SqlLine.main(SqlLine.java:206)
Caused by: java.util.concurrent.ExecutionException:
java.lang.IllegalArgumentException: Timestamp cannot be negative.
minStamp:9223372036854775807, maxStamp:-9223372036854775808
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:206)
at
org.apache.phoenix.iterate.BaseResultIterators.getIterators(BaseResultIterators.java:1374)
... 16 more
Caused by: java.lang.IllegalArgumentException: Timestamp cannot be negative.
minStamp:9223372036854775807, maxStamp:-9223372036854775808
at org.apache.hadoop.hbase.io.TimeRange.check(TimeRange.java:157)
at org.apache.hadoop.hbase.io.TimeRange.(TimeRange.java:145)
at org.apache.hadoop.hbase.client.Get.setTimestamp(Get.java:238)
at
org.apache.omid.transaction.HBaseTransactionManager$CommitTimestampLocatorImpl.readCommitTimestampFromShadowCell(HBaseTransactionManager.java:299)
at
org.apache.omid.transaction.SnapshotFilterImpl.readCommitTimestampFromShadowCell(SnapshotFilterImpl.java:143)
at
org.apache.omid.transaction.SnapshotFilterImpl.locateCellCommitTimestamp(SnapshotFilterImpl.java:188)
at
org.apache.omid.transaction.SnapshotFilterImpl.tryToLocateCellCommitTimestamp(SnapshotFilterImpl.java:250)
at
org.apache.omid.transaction.SnapshotFilterImpl.getCommitTimestamp(SnapshotFilterImpl.java:303)
at
org.apache.omid.transaction.SnapshotFilterImpl.getTSIfInSnapshot(SnapshotFilterImpl.java:388)
at
org.apache.omid.transaction.SnapshotFilterImpl.filterCellsForSnapshot(SnapshotFilterImpl.java:449)
at
org.apache.omid.transaction.SnapshotFilterImpl$TransactionalClientScanner.next(SnapshotFilterImpl.java:633)
at
org.apache.phoenix.iterate.ScanningResultIterator.next(ScanningResultIterator.java:158)
at
org.apache.phoenix.iterate.TableResultIterator.next(TableResultIterator.java:172)
at
org.apache.phoenix.iterate.LookAheadResultIterator$1.advance(LookAheadResultIterator.java:55)
at
org.apache.phoenix.iterate.LookAheadResultIterator.init(LookAheadResultIterator.java:67)
at
org.apache.phoenix.iterate.LookAheadResultIterator.peek(LookAheadResultIterator.java:81)
at
org.apache.phoenix.iterate.ParallelIterators$1.call(ParallelIterators.java:138)
at
org.apache.phoenix.iterate.ParallelIterators$1.call(ParallelIterators.java:121)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17789945#comment-17789945
]
Istvan Toth edited comment on OMID-240 at 11/27/23 7:50 AM:
Actually, I think we could just refuse to start TSO server for that invalid
combination of in-memory modules and HA.
was (Author: stoty):
Actually, I think we could just refuse to start TSO server for that invalid
combination.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788657#comment-17788657
]
Istvan Toth edited comment on OMID-240 at 11/22/23 11:36 AM:
-
If it is used and is needed for tests, then making it functional seems to be
the right thing to do, so that the testing environment behaves like a
production one.
was (Author: stoty):
If it used and needed for tests, then making it functional seems to be the
right thing to do, so that the testing environment behaves like a production
one.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788657#comment-17788657
]
Istvan Toth edited comment on OMID-240 at 11/22/23 7:21 AM:
If it used and needed for tests, then making it functional seems to be the
right thing to do, so that the testing environment behaves like a production
one.
was (Author: stoty):
If it used and needed for tests implementation, then making it functional seems
to be the right thing to do, so that the testing environment behaves like a
production one.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788657#comment-17788657
]
Istvan Toth edited comment on OMID-240 at 11/22/23 7:21 AM:
If it used and needed for tests implementation, then making it functional seems
to be the right thing to do, so that the testing environment behaves like a
production one.
was (Author: stoty):
If it used and needed for tests implementation, then making it functional seems
to be the right thing to do, so that we the testing environment behaves like a
production one.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17788611#comment-17788611
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/22/23 4:16 AM:
Currently with default configurations client TSO server initialising with
inmemory storage modules.
- With InMemoryCommitTableStorageModule, NullCommitTable is getting used which
doesn't maintain any commit timestamps information.
{noformat}
public class InMemoryCommitTableStorageModule extends AbstractModule {
@Override
public void configure() {
bind(CommitTable.class).to(NullCommitTable.class).in(Singleton.class);
}
}
{noformat}
{noformat}
public static class Writer implements CommitTable.Writer {
@Override
public void addCommittedTransaction(long startTimestamp, long
commitTimestamp) {
// noop
}
{noformat}
- What ever the commit timestamp generated by Transaction Oracle persisted in
shadow cells only.
- At the same time in the server side HBase Commit Table is getting used to
fetch the commit timestamp of the transactions which will not have any
information because TSO not writing to Hbase commit table.
{noformat}
connection = RegionConnectionFactory
.getConnection(RegionConnectionFactory.ConnectionType.READ_CONNECTION,
(RegionCoprocessorEnvironment) env);
commitTableClient = new HBaseCommitTable(connection,
commitTableConf).getClient();
LOG.info("Snapshot filter started");
{noformat}
- During the commit the tso client updates the shadow cells with the commit
timestamp.
{noformat}
private void commitRegularTransaction(AbstractTransaction
tx)
throws RollbackException, TransactionException
{
try {
long commitTs = tsoClient.commit(tx.getStartTimestamp(),
tx.getWriteSet(), tx.getConflictFreeWriteSet()).get();
certifyCommitForTx(tx, commitTs);
updateShadowCellsAndRemoveCommitTableEntry(tx, postCommitter);
{noformat}
- Omid Filters at the server checks for commit timestamp from shadow cells or
commit table, while filtering chances of the cells will be skipped, if commit
timestamp available neither in shadow cells not commit table. This is what
happening when both commit and scan running at the same time and mismatch is
number of records.
{noformat}
if (CellUtils.isShadowCell(v)) {
Long commitTs = Bytes.toLong(CellUtil.cloneValue(v));
commitCache.put(v.getTimestamp(), commitTs);
// Continue getting shadow cells until one of them fits this
transaction
if (hbaseTransaction.getStartTimestamp() >= commitTs) {
return ReturnCode.NEXT_COL;
} else {
return ReturnCode.SKIP;
}
}
Optional commitTS = getCommitIfInSnapshot(v,
CellUtils.isFamilyDeleteCell(v));
if (commitTS.isPresent()) {
}
return ReturnCode.SKIP;
{noformat}
This issue is not happening when HBase Storage Modules is configured for TSO
server where the omid filters can find the commit timestamp in case of shadow
cells doens't have.
So it can be avoided with proper usage the HBase storage modules in TSO server.
[~stoty] I think this can be closed as not an issue. WDYT?
was (Author: rajeshbabu):
Currently with default configurations client TSO server initialising with
inmemory storage modules.
- With InMemoryCommitTableStorageModule, NullCommitTable is getting used which
doesn't maintain any commit timestamps information.
- What ever the commit timestamp generated by Transaction Oracle persisted in
shadow cells only.
- At the same time in the server side HBase Commit Table is getting used to
fetch the commit timestamp of the transactions which will not have any
information because TSO not writing to Hbase commit table.
- During the commit the tso client updates the shadow cells with the commit
timestamp.
- Omid Filters at the server checks for commit timestamp from shadow cells or
commit table, while filtering chances of the cells will be skipped, if commit
timestamp available neither in shadow cells not commit table. This is what
happening when both commit and scan running at the same time and mismatch is
number of records.
This issue is not happening when HBase Storage Modules is configured for TSO
server where the omid filters can find the commit timestamp in case of shadow
cells doens't have.
So it can be avoided with proper usage the HBase storage modules in TSO server.
[~stoty] I think this can be closed as not an issue. WDYT?
> Transactional visibility is broken
> --
>
> Key: OMID-240
> URL: https://issues.apache.org/jira/browse/OMID-240
> Project: Phoenix Omid
> Issue Type: Bug
>
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786871#comment-17786871
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/16/23 5:41 PM:
This issue happening with Inmemory timestamp and commit tables. With HBase
timestamp and commit tables not able to reproduce this even after 100s
attempts. Now checking why it's happening with Inmemory tables with additional
logging.
was (Author: rajeshbabu):
This issue happening with Inmemory timestamp and commit tables. With HBase
timestamp and commit tables not able to reproduce this even ran 100s of times.
Now checking why it's happening with Inmemory tables with additional logging.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786871#comment-17786871
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/16/23 5:36 PM:
This issue happening with Inmemory timestamp and commit tables. With HBase
timestamp and commit tables not able to reproduce this even ran 100s of times.
Now checking why it's happening with Inmemory tables with additional logging.
was (Author: rajeshbabu):
This issue happening with Inmemory timestamp and commit tables used. With HBase
timestamp and commit table not able to reproduce this.
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782091#comment-17782091
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/2/23 11:29 AM:
Here is the metadata of the hfile gives the timeranges of cells in the post
commit.
{noformat}
reader=/apps/hbase/data/data/default/TEST/054c7bae986e6b6f6625dd7d898b1839/0/aa83662a8d2740b4a94fb23f514b9f03,
compression=none,
cacheConf=cacheDataOnRead=false,
cacheDataOnWrite=false,
cacheIndexesOnWrite=false,
cacheBloomsOnWrite=false,
cacheEvictOnClose=false,
cacheDataCompressed=false,
prefetchOnOpen=false,
firstKey=Optional[\xB5E\xDDZ/0:\x00\xC2\x80Y\xC2\x80/169891724228614/Put/seqid=0],
lastKey=Optional[\xBF\x7F\xFF\xE9/0:_0/169891724228616/Put/seqid=0],
avgKeyLen=21,
avgValueLen=5,
entries=1043920,
length=15539025
Trailer:
fileinfoOffset=15534307,
loadOnOpenDataOffset=15515573,
dataIndexCount=593,
metaIndexCount=0,
totalUncomressedBytes=15515484,
entryCount=1043920,
compressionCodec=NONE,
uncompressedDataIndexSize=18656,
numDataIndexLevels=1,
firstDataBlockOffset=0,
lastDataBlockOffset=15447293,
comparatorClassName=org.apache.hadoop.hbase.CellComparatorImpl,
encryptionKey=NONE,
majorVersion=3,
minorVersion=3
Fileinfo:
BLOOM_FILTER_TYPE = ROW
COMPACTION_EVENT_KEY = PBUF
DATA_BLOCK_ENCODING = FAST_DIFF
DELETE_FAMILY_COUNT = 0
EARLIEST_PUT_TS = 169891724228600
KEY_VALUE_VERSION = 1
LAST_BLOOM_KEY = \xBF\x7F\xFF\xE9
MAJOR_COMPACTION_KEY = false
MAX_MEMSTORE_TS_KEY = 3152
MAX_SEQ_ID_KEY = 3153
TIMERANGE = 169891724228600169891724228618
hfile.AVG_KEY_LEN = 21
hfile.AVG_VALUE_LEN = 5
hfile.CREATE_TIME_TS = 1698917556166
hfile.LASTKEY = \xBF\x7F\xFF\xE9/0:_0/169891724228616/Put/vlen=0/mvcc=0
Mid-key: Optional[\xBF\x00-k/0:\x01/LATEST_TIMESTAMP/Maximum/seqid=0]
{noformat}
{noformat} TIMERANGE = 169891724228600169891724228618 {noformat}
First scan info giving wrong result
{noformat}
2023-11-02 09:29:16,469 TRACE
[RpcServer.default.FPBQ.Fifo.handler=49,queue=1,port=16020] ipc.RpcServer:
callId: 37 service: ClientService methodName: Scan size: 581 connection:
:51462 deadline: 1698917407892 param: region \{ type: REGION_NAME
value: "TEST,,1698917228121.054c7bae986e6b6f6625dd7d898b1839." } scan \{ column
{ family: "0" } attribute \{ name: "_ClientVersion" value: "\000\005\001\000" }
attribute \{ name: "__OMID_LL__" value: "\000" } attribute \{ name:
"__OMID_TRANSACTION__" value:
"\b\200\211\374\346\271\212\361\311\027\020\200\211\374\346\271\212\361\311\027\030\000
\377\377\377\377\377\377\377\377\377\001" } attribute \{ name: "_UngroupedAgg"
value: "\001" } attribute \{ name: "_ServerPageSizeMs" value:
"\000\000\000\000\000\000\257\310" } attribute \{ name:
"_UseNewValueColumnQualifier" value: "\377" } attribute \{ name: "_Aggs" value:
"\001\001\030\001\003\005\200\000\000\001\006\003" } attribute \{ name:
"_QualifierEncodingScheme" value: "\000" } attribute \{ name:
"_ImmutableStorageEncodingScheme" value: "\001" } attribute \{ name:
"_ScanActualStartRow" value: "" } attribute \{ name: "_isolationlevel_" value:
"\000" } attribute \{ name: "_SCAN_REGION_SERVER" value:
"\000\000host1,16020,1698917094253" } filter \{ name:
"org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter" serialized_filter: "" }
time_range \{ from: 0 to: 169891734784201 } max_versions: 1 cache_blocks:
true max_result_size: 2097152 load_column_families_on_demand: true caching: 100
include_stop_row: false } number_of_rows: 100 close_scanner: false
client_handles_partials: true client_handles_heartbeats: true
track_scan_metrics: false connection: 10.211.61.94:51462, response:
cells_per_result: 1 scanner_id: 8745977501257302081 more_results: true ttl:
6 stale: false partial_flag_per_result: false more_results_in_region: false
mvcc_read_point: 2711, receiveTime: 1698917347892, queueTime: 1,
processingTime: 8576, totalTime: 8577
{noformat}
Further scans info giving correct results.
{noformat}
2023-11-02 09:29:26,658 TRACE
[RpcServer.default.FPBQ.Fifo.handler=49,queue=1,port=16020] ipc.RpcServer:
callId: 41 service: ClientService methodName: Scan size: 581 connection:
:51462 deadline: 1698917418631 param: region \{ type: REGION_NAME
value: "TEST,,1698917228121.054c7bae986e6b6f6625dd7d898b1839." } scan \{ column
{ family: "0" } attribute \{ name: "_ClientVersion" value: "\000\005\001\000" }
attribute \{ name: "__OMID_LL__" value: "\000" } attribute \{ name:
"__OMID_TRANSACTION__" value:
"\b\200\356\207\353\341\212\361\311\027\020\200\356\207\353\341\212\361\311\027\030\000
\377\377\377\377\377\377\377\377\377\001" } attribute \{ name: "_UngroupedAgg"
value: "\001" } attribute \{ name:
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782091#comment-17782091
]
Rajeshbabu Chintaguntla edited comment on OMID-240 at 11/2/23 10:51 AM:
Here is the metadata of the hfile gives the timeranges of cells in the post
commit.
{noformat}
reader=/apps/hbase/data/data/default/TEST/054c7bae986e6b6f6625dd7d898b1839/0/aa83662a8d2740b4a94fb23f514b9f03,
compression=none,
cacheConf=cacheDataOnRead=false,
cacheDataOnWrite=false,
cacheIndexesOnWrite=false,
cacheBloomsOnWrite=false,
cacheEvictOnClose=false,
cacheDataCompressed=false,
prefetchOnOpen=false,
firstKey=Optional[\xB5E\xDDZ/0:\x00\xC2\x80Y\xC2\x80/169891724228614/Put/seqid=0],
lastKey=Optional[\xBF\x7F\xFF\xE9/0:_0/169891724228616/Put/seqid=0],
avgKeyLen=21,
avgValueLen=5,
entries=1043920,
length=15539025
Trailer:
fileinfoOffset=15534307,
loadOnOpenDataOffset=15515573,
dataIndexCount=593,
metaIndexCount=0,
totalUncomressedBytes=15515484,
entryCount=1043920,
compressionCodec=NONE,
uncompressedDataIndexSize=18656,
numDataIndexLevels=1,
firstDataBlockOffset=0,
lastDataBlockOffset=15447293,
comparatorClassName=org.apache.hadoop.hbase.CellComparatorImpl,
encryptionKey=NONE,
majorVersion=3,
minorVersion=3
Fileinfo:
BLOOM_FILTER_TYPE = ROW
COMPACTION_EVENT_KEY = PBUF
DATA_BLOCK_ENCODING = FAST_DIFF
DELETE_FAMILY_COUNT = 0
EARLIEST_PUT_TS = 169891724228600
KEY_VALUE_VERSION = 1
LAST_BLOOM_KEY = \xBF\x7F\xFF\xE9
MAJOR_COMPACTION_KEY = false
MAX_MEMSTORE_TS_KEY = 3152
MAX_SEQ_ID_KEY = 3153
TIMERANGE = 169891724228600169891724228618
hfile.AVG_KEY_LEN = 21
hfile.AVG_VALUE_LEN = 5
hfile.CREATE_TIME_TS = 1698917556166
hfile.LASTKEY = \xBF\x7F\xFF\xE9/0:_0/169891724228616/Put/vlen=0/mvcc=0
Mid-key: Optional[\xBF\x00-k/0:\x01/LATEST_TIMESTAMP/Maximum/seqid=0]
{noformat}
{noformat} TIMERANGE = 169891724228600169891724228618 {noformat}
First scan info giving wrong result
{noformat}
2023-11-02 09:29:16,469 TRACE
[RpcServer.default.FPBQ.Fifo.handler=49,queue=1,port=16020] ipc.RpcServer:
callId: 37 service: ClientService methodName: Scan size: 581 connection:
:51462 deadline: 1698917407892 param: region \{ type: REGION_NAME
value: "TEST,,1698917228121.054c7bae986e6b6f6625dd7d898b1839." } scan \{ column
{ family: "0" } attribute \{ name: "_ClientVersion" value: "\000\005\001\000" }
attribute \{ name: "__OMID_LL__" value: "\000" } attribute \{ name:
"__OMID_TRANSACTION__" value:
"\b\200\211\374\346\271\212\361\311\027\020\200\211\374\346\271\212\361\311\027\030\000
\377\377\377\377\377\377\377\377\377\001" } attribute \{ name: "_UngroupedAgg"
value: "\001" } attribute \{ name: "_ServerPageSizeMs" value:
"\000\000\000\000\000\000\257\310" } attribute \{ name:
"_UseNewValueColumnQualifier" value: "\377" } attribute \{ name: "_Aggs" value:
"\001\001\030\001\003\005\200\000\000\001\006\003" } attribute \{ name:
"_QualifierEncodingScheme" value: "\000" } attribute \{ name:
"_ImmutableStorageEncodingScheme" value: "\001" } attribute \{ name:
"_ScanActualStartRow" value: "" } attribute \{ name: "_isolationlevel_" value:
"\000" } attribute \{ name: "_SCAN_REGION_SERVER" value:
"\000\000host1,16020,1698917094253" } filter \{ name:
"org.apache.hadoop.hbase.filter.FirstKeyOnlyFilter" serialized_filter: "" }
time_range \{ from: 0 to: 169891734784201 } max_versions: 1 cache_blocks:
true max_result_size: 2097152 load_column_families_on_demand: true caching: 100
include_stop_row: false } number_of_rows: 100 close_scanner: false
client_handles_partials: true client_handles_heartbeats: true
track_scan_metrics: false connection: 10.211.61.94:51462, response:
cells_per_result: 1 scanner_id: 8745977501257302081 more_results: true ttl:
6 stale: false partial_flag_per_result: false more_results_in_region: false
mvcc_read_point: 2711, receiveTime: 1698917347892, queueTime: 1,
processingTime: 8576, totalTime: 8577
{noformat}
Further scans info giving correct results.
{noformat}
2023-11-02 09:29:26,658 TRACE
[RpcServer.default.FPBQ.Fifo.handler=49,queue=1,port=16020] ipc.RpcServer:
callId: 41 service: ClientService methodName: Scan size: 581 connection:
:51462 deadline: 1698917418631 param: region \{ type: REGION_NAME
value: "TEST,,1698917228121.054c7bae986e6b6f6625dd7d898b1839." } scan \{ column
{ family: "0" } attribute \{ name: "_ClientVersion" value: "\000\005\001\000" }
attribute \{ name: "__OMID_LL__" value: "\000" } attribute \{ name:
"__OMID_TRANSACTION__" value:
"\b\200\356\207\353\341\212\361\311\027\020\200\356\207\353\341\212\361\311\027\030\000
\377\377\377\377\377\377\377\377\377\001" } attribute \{ name: "_UngroupedAgg"
value: "\001" } attribute \{ name:
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710359#comment-17710359
]
Lars Hofhansl edited comment on OMID-240 at 4/11/23 12:59 AM:
--
Happens whether PostCommitMode is SYNC or ASYNC, and ConflictDetectionLevel is
ROW or CELL.
So it looks like this is generally broken!
was (Author: lhofhansl):
Happens whether PostCommitMode is SYNC or ASYNC
> 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
>Priority: Major
> 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)
[jira] [Comment Edited] (OMID-240) Transactional visibility is broken with PosCommitMode = ASYNC
[
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17710358#comment-17710358
]
Lars Hofhansl edited comment on OMID-240 at 4/11/23 12:39 AM:
--
I don't work on Phoenix/HBase/OMID anymore, and won't have a fix. But at least
I can file this issue.
Find my OMID config files attached.
was (Author: lhofhansl):
I don't work on Phoenix/HBase/OMID anymore, and won't have a fix. But at least
I can file this issue.
> Transactional visibility is broken with PosCommitMode = ASYNC
> -
>
> 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
>Priority: Major
> 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;
> -- 18x
> > !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)
