[jira] [Commented] (OMID-240) Transactional visibility is broken

2023-12-17 Thread Lars Hofhansl (Jira) 


[ 
https://issues.apache.org/jira/browse/OMID-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798032#comment-17798032
 ] 

Lars Hofhansl commented on OMID-240:


Awesome. Thank you!

> 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
> Fix For: 1.1.1
>
> 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] [Updated] (PHOENIX-7106) Data Integrity issues due to invalid rowkeys returned by various coprocessors

2023-12-17 Thread Viraj Jasani (Jira) 


 [ 
https://issues.apache.org/jira/browse/PHOENIX-7106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viraj Jasani updated PHOENIX-7106:
--
Summary: Data Integrity issues due to invalid rowkeys returned by various 
coprocessors  (was: Invalid rowkey returned by coproc can cause data integrity 
issues)

> Data Integrity issues due to invalid rowkeys returned by various coprocessors
> -
>
> Key: PHOENIX-7106
> URL: https://issues.apache.org/jira/browse/PHOENIX-7106
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Viraj Jasani
>Assignee: Viraj Jasani
>Priority: Critical
> Fix For: 5.2.0, 5.1.4
>
>
> HBase scanner interface expects server to perform scan of the cells from 
> HFile or Block cache and return consistent data i.e. rowkey of the cells 
> returned should stay in the range of the scan boundaries. When a region moves 
> and scanner needs reset, or if the current row is too large and the server 
> returns partial row, the subsequent scanner#next is supposed to return 
> remaining cells. When this happens, cell rowkeys returned by servers i.e. any 
> coprocessors is expected to be in the scan boundary range so that server can 
> reliably perform its validation and return remaining cells as expected.
> Phoenix client initiates serial or parallel scans from the aggregators based 
> on the region boundaries and the scan boundaries are sometimes adjusted based 
> on where optimizer provided key ranges, to include tenant boundaries, salt 
> boundaries etc. After the client opens the scanner and performs scan 
> operation, some of the coprocs return invalid rowkey for the following cases:
>  # Grouped aggregate queries
>  # Ungrouped aggregate queries (not all of them)
>  # Offset queries
>  # Some dummy cells returned with empty rowkey
>  # Update statistics queries
>  # Local indexes
> Since many of these cases return reserved rowkeys, they are likely not going 
> to match scan or region boundaries. It has potential to cause data integrity 
> issues in certain scenarios as explained above. Empty rowkey returned by 
> server can be treated as end of the region scan by HBase client.
> With the paging feature enabled, if the page size is kept low, we have higher 
> chances of scanners returning dummy cell, resulting in increased num of RPC 
> calls for better latency and timeouts. We should return only valid rowkey in 
> the scan range for all the cases where we perform above mentioned operations 
> like complex aggregate or offset queries etc.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release of Apache Phoenix Thirdparty 2.1.0 RC0

2023-12-17 Thread rajeshb...@apache.org 
Yes Istvan, mail template needs cleanup.

Can we get few more votes for this release?

Thanks,
Rajeshbabu.

On Thu, Dec 14, 2023, 10:27 AM Istvan Toth 
wrote:

> The vote email template is out of date.
> The current ASF infra doesn't make it possible to get a direct link to the
> artifacts (or at least I couldn't figure out how to do that)
> Next time you may want to include the repository name, in case it's not
> obvious (multiple RCs or similar reason)
>
> On Thu, Dec 14, 2023 at 5:23 AM rajeshb...@apache.org <
> chrajeshbab...@gmail.com> wrote:
>
> > Hi NIhal,
> >
> > The artifacts can show at
> > https://repository.apache.org/#stagingRepositories
> > PFA screenshot.
> >
> > Once closed those will be published to the path.
> >
> > Thanks,
> > Rajeshbabu.
> >
> > On Wed, Dec 13, 2023 at 10:29 PM Nihal Jain 
> > wrote:
> >
> >> +1 (non-binding)
> >>
> >> * Signature: OK
> >> * Checksum: OK
> >> * Rat check (1.8.0_381-b09): OK
> >>   - mvn clean apache-rat:check
> >> * Build from source (1.8.0_381-b09): OK
> >>- mvn clean install
> >>
> >> Also, checked out latest phoenix master and built code (1.8.0_381-b09):
> OK
> >>   - mvn clean install -DskipTests -Dphoenix.thirdparty.version=2.1.0
> >>
> >> Repeated above step for branch 5.1: OK
> >>
> >> NOTE: I could not find the jars under
> >>
> >>
> https://repository.apache.org/content/repositories/staging/org/apache/phoenix/thirdparty/phoenix-thirdparty/
> >>
> >> Could you please check?
> >>
> >> Regards,
> >> Nihal
> >>
> >> On Wed, 13 Dec 2023, 15:04 Istvan Toth, 
> >> wrote:
> >>
> >> > +1 (binding)
> >> >
> >> > - Built and installed the commit locally
> >> > - Ran "mvn clean package -Dphoenix.thirdparty.version=2.1.0"
> >> successfully
> >> > on 5.1 and master
> >> > - Run smoke test successfully with phoenix-sandbox on 5.1
> >> > - Release notes look good
> >> > - Checksum is OK
> >> > - Signature is OK
> >> >
> >> > Istvan
> >> >
> >> > On Wed, Dec 13, 2023 at 6:49 AM rajeshb...@apache.org <
> >> > chrajeshbab...@gmail.com> wrote:
> >> >
> >> > > Please vote on this Apache phoenix thirdparty release candidate,
> >> > > phoenix-thirdparty-2.1.0RC0
> >> > >
> >> > > The VOTE will remain open for at least 72 hours.
> >> > >
> >> > > [ ] +1 Release this package as Apache phoenix thirdparty 2.1.0
> >> > > [ ] -1 Do not release this package because ...
> >> > >
> >> > > The tag to be voted on is 2.1.0RC0:
> >> > >
> >> > >   https://github.com/apache/phoenix-thirdparty/tree/2.1.0RC0
> >> > >
> >> > > The release files, including signatures, digests, as well as
> >> CHANGES.md
> >> > > and RELEASENOTES.md included in this RC can be found at:
> >> > >
> >> > >
> >> > >
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/phoenix-thirdparty-2.1.0RC0/
> >> > >
> >> > > Maven artifacts are available in a staging repository at:
> >> > >
> >> > >   https://repository.apache.org/content/repositories//
> >> > >
> >> > > Artifacts were signed with the 0x2CC0FD99 key which can be found in:
> >> > >
> >> > >   https://dist.apache.org/repos/dist/release/phoenix/KEYS
> >> > >
> >> > > To learn more about Apache phoenix thirdparty, please see
> >> > >
> >> > >   https://phoenix.apache.org/
> >> > >
> >> > > Thanks,
> >> > > Rajeshbabu Chintaguntla
> >> > >
> >> >
> >> >
> >> > --
> >> > *István Tóth* | Sr. Staff Software Engineer
> >> > *Email*: st...@cloudera.com
> >> > cloudera.com 
> >> > [image: Cloudera] 
> >> > [image: Cloudera on Twitter]  [image:
> >> > Cloudera on Facebook]  [image:
> >> Cloudera
> >> > on LinkedIn] 
> >> > --
> >> > --
> >> >
> >>
> >
>
> --
> *István Tóth* | Sr. Staff Software Engineer
> *Email*: st...@cloudera.com
> cloudera.com 
> [image: Cloudera] 
> [image: Cloudera on Twitter]  [image:
> Cloudera on Facebook]  [image: Cloudera
> on LinkedIn] 
> --
> --
>