[jira] [Created] (OMID-271) Support HBase 3

[Istvan Toth (Jira)]

Istvan Toth created OMID-271:


 Summary: Support HBase 3
 Key: OMID-271
 URL: https://issues.apache.org/jira/browse/OMID-271
 Project: Phoenix Omid
  Issue Type: New Feature
Affects Versions: 1.1.1
Reporter: Istvan Toth






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

Re: [VOTE] Release of Apache Phoenix Omid 1.1.1 RC0

[Istvan Toth]

I think we should look into this a bit deeper.
Why does this fail with IPv6 ?

Are we explicitly binding TSO to the IPv4 address only ?
Do we only do that in the tests, or does that happen in production ?
Is it even possible to use Omid with IPv6 ?

I suspect that fixing https://issues.apache.org/jira/browse/OMID-249 would
improve on this.

Generally, I think that having a single IP per TSO can be a problem in a
mixed IPv4 / IPv6 network, and with some network configurations.
Maybe we should store the name of the active server instead of addresses in
ZK, and kick this problem down to the network/DNS administrator.

If Omid is known to not work with IPV6 in 1.1.0 , then I'm OK with Cong's
proposed solution, but if it breaks pre-existing Ipv6 support, then we
should
fix this properly for 1.1.1.

We should create a follow-up ticket to make sure the Omid is IPv6 clean for
the next release at the very least.

Istvan


On Thu, Jan 18, 2024 at 6:56 AM Cong Luo  wrote:

> Hi Richard,
>   Actually, I had the same issue before, but it was resolved locally: if
> the NIC was assigned both ipv4 and ipv6 addresses, use ipv4 first. If we
> all think this is acceptable, then I will create a PR submission.
>
> On 2024/01/17 14:30:50 Richárd Antal wrote:
> > -1
> >
> > Signature: OK
> > Checksum: OK
> > mvn clean apache-rat:check: OK
> >
> > Changes and release notes: OK
> >
> > Built from source (1.8.0_241): OK
> >   - mvn clean install  -DskipTests
> > Ran tests on my MacBook locally:
> >   - mvn clean verify : Failed
> > TestTSOClientConnectionToTSO had failing tests:
> > testSuccessfulConnectionToTSOThroughZK and
> > testSuccessOfTSOClientReconnectionsToARestartedTSOWithZKPublishing
> > It might be because it uses IPv6
> > Some logs
> >
> > 2024-01-17T15:17:45,858 INFO
> > >  [TestNGInvoker-testSuccessfulConnectionToTSOThroughZK()]
> client.TSOClient:
> > > * Current TSO host:port found in ZK:
> > > [fe80:0:0:0:aede:48ff:fe00:1122%en5]:52934 Epoch 0
> > > 2024-01-17T15:17:45,859 INFO  [tsofsm-0] client.TSOClient: Trying to
> > > connect to TSO [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934]
> > > 2024-01-17T15:17:45,863 ERROR [tsoclient-worker-0] client.TSOClient:
> > > Failed connection attempt to TSO
> > > [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934] failed. Channel [id:
> 0x9d8c0b44]
> >
> >
> > I’ve also tested the TestTSOClientConnectionToTSO on the 1.1.0 release
> > locally and that was successful (It used IPv4).
> > I think this is a regression on Mac and it would be nice to fix before
> the
> > release.
> >
> > Richard
> >
> > Cong Luo  ezt írta (időpont: 2024. jan. 11., Cs, 3:52):
> >
> > > +1
> > >
> > > I did a basic test last month in the test environment (fully
> distributed)
> > > based on phoenix 5.1.3 + omid 1.1.1 and did not find a blocking issue.
> > >
> > > On 2024/01/09 12:53:28 "rajeshb...@apache.org" wrote:
> > > > Please vote on this Apache phoenix omid release candidate,
> > > > phoenix-omid-1.1.1RC0
> > > >
> > > > The VOTE will remain open for at least 72 hours.
> > > >
> > > > [ ] +1 Release this package as Apache phoenix omid 1.1.1
> > > > [ ] -1 Do not release this package because ...
> > > >
> > > > The tag to be voted on is 1.1.1RC0:
> > > >
> > > >   https://github.com/apache/phoenix-omid/tree/1.1.1RC0
> > > >
> > > > 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-omid-1.1.1RC0/
> > > >
> > > > Maven artifacts are available in a staging repository at:
> > > >
> > > >
> > >
> https://repository.apache.org/content/repositories/orgapachephoenix-1251/
> > > >
> > > > 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 omid, please see
> > > >
> > > >   https://phoenix.apache.org/
> > > >
> > > > Thanks,
> > > > Rajeshbabu.
> > > >
> > >
> >
>


-- 
*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] 
--
--

[jira] [Commented] (OMID-249) Remove default network interface logic

[Istvan Toth (Jira)]

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

Istvan Toth commented on OMID-249:
--

Or maybe use the hostname in ZK, to solve IPv4/IPv6 and multihomed host issues.

> Remove default network interface logic
> --
>
> Key: OMID-249
> URL: https://issues.apache.org/jira/browse/OMID-249
> Project: Phoenix Omid
>  Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Istvan Toth
>Priority: Major
>
> NetworkUtils.getNetworkInterface() seems to be only used for determining the 
> host and port when registering TSO to ZK for HA.
> We should get the TSO public IP from the ZK TCP connection on demand, and not 
> worry about the default network interface at all.



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

Re: [ANNOUNCE] Lokesh Khurana as Phoenix Committer

[rajeshb...@apache.org]

Congratulations Lokesh!!

On Wed, Jan 17, 2024, 10:55 PM Viraj Jasani  wrote:

> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Lokesh
> Khurana has accepted the PMC's invitation to become a committer on Apache
> Phoenix.
>
> We appreciate all of the great contributions Lokesh has made to the
> community thus far and we look forward to his continued involvement.
>
> Congratulations and Welcome, Lokesh!
>

Re: [VOTE] Release of Apache Phoenix Omid 1.1.1 RC0

[Cong Luo]

Hi Richard,
  Actually, I had the same issue before, but it was resolved locally: if the 
NIC was assigned both ipv4 and ipv6 addresses, use ipv4 first. If we all think 
this is acceptable, then I will create a PR submission.

On 2024/01/17 14:30:50 Richárd Antal wrote:
> -1
> 
> Signature: OK
> Checksum: OK
> mvn clean apache-rat:check: OK
> 
> Changes and release notes: OK
> 
> Built from source (1.8.0_241): OK
>   - mvn clean install  -DskipTests
> Ran tests on my MacBook locally:
>   - mvn clean verify : Failed
> TestTSOClientConnectionToTSO had failing tests:
> testSuccessfulConnectionToTSOThroughZK and
> testSuccessOfTSOClientReconnectionsToARestartedTSOWithZKPublishing
> It might be because it uses IPv6
> Some logs
> 
> 2024-01-17T15:17:45,858 INFO
> >  [TestNGInvoker-testSuccessfulConnectionToTSOThroughZK()] client.TSOClient:
> > * Current TSO host:port found in ZK:
> > [fe80:0:0:0:aede:48ff:fe00:1122%en5]:52934 Epoch 0
> > 2024-01-17T15:17:45,859 INFO  [tsofsm-0] client.TSOClient: Trying to
> > connect to TSO [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934]
> > 2024-01-17T15:17:45,863 ERROR [tsoclient-worker-0] client.TSOClient:
> > Failed connection attempt to TSO
> > [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934] failed. Channel [id: 0x9d8c0b44]
> 
> 
> I’ve also tested the TestTSOClientConnectionToTSO on the 1.1.0 release
> locally and that was successful (It used IPv4).
> I think this is a regression on Mac and it would be nice to fix before the
> release.
> 
> Richard
> 
> Cong Luo  ezt írta (időpont: 2024. jan. 11., Cs, 3:52):
> 
> > +1
> >
> > I did a basic test last month in the test environment (fully distributed)
> > based on phoenix 5.1.3 + omid 1.1.1 and did not find a blocking issue.
> >
> > On 2024/01/09 12:53:28 "rajeshb...@apache.org" wrote:
> > > Please vote on this Apache phoenix omid release candidate,
> > > phoenix-omid-1.1.1RC0
> > >
> > > The VOTE will remain open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache phoenix omid 1.1.1
> > > [ ] -1 Do not release this package because ...
> > >
> > > The tag to be voted on is 1.1.1RC0:
> > >
> > >   https://github.com/apache/phoenix-omid/tree/1.1.1RC0
> > >
> > > 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-omid-1.1.1RC0/
> > >
> > > Maven artifacts are available in a staging repository at:
> > >
> > >
> > https://repository.apache.org/content/repositories/orgapachephoenix-1251/
> > >
> > > 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 omid, please see
> > >
> > >   https://phoenix.apache.org/
> > >
> > > Thanks,
> > > Rajeshbabu.
> > >
> >
> 

Re: [DISCUSS] 5.2.0 priority : PHOENIX-7106 Data Integrity Issues

[Rushabh Shah]

Thank you Viraj for initiating this thread.

> Given the critical nature of these issues, I would like to propose that we
treat this as a high priority for the upcoming 5.2.0 release, and not
include any other feature or big change to master branch until we merge
this.

Do you think cutting 5.2.0 now makes sense? This will enable other
developers to merge features into master branch (5.3.0) and you can take
some more time to make sure we cover all the corner cases for the data
integrity issues that you uncovered.


On Fri, Jan 5, 2024 at 6:38 PM Viraj Jasani  wrote:

> Sounds good, thanks Rajeshbabu. I will try to get the first PR out next
> week and while reviews happen in parallel, will try to get 5.1 PR soon.
>
>
> On Wed, Jan 3, 2024 at 8:49 PM rajeshb...@apache.org <
> chrajeshbab...@gmail.com> wrote:
>
> > Hi Viraj,
> >
> > Would be better to include the changes in 5.1.4  as in any way it will
> take
> > at least 3-4 days to complete the omid release.
> >
> > Thanks,
> > Rajeshbabu.
> >
> >
> > On Thu, Jan 4, 2024 at 5:06 AM Viraj Jasani  wrote:
> >
> > > Thank you Kadir and Geoffrey for your replies!!
> > >
> > > > How does this affect 5.1.4, which is also listed as a Fix Version for
> > > > PHOENIX-7106?
> > >
> > > Yes, it also needs to be ported to 5.1. Once the master PR is up for
> > final
> > > review, I would start working on the backport PR.
> > > We just need some more additional testing to ensure old client (e.g.
> > 5.1.3)
> > > is compatible with the new server with the changes.
> > >
> > > Hence, yes it is now a blocker for upcoming 5.1.4 as well since 5.1.4
> RC
> > > preparation is still pending (while Omid release is in progress).
> > > Otherwise if 5.1.4 was ready for release, I would have proposed
> immediate
> > > 5.1.5 release to include the changes proposed with PHOENIX-7106.
> > >
> > >
> > > On Wed, Jan 3, 2024 at 3:08 PM Geoffrey Jacoby 
> > wrote:
> > >
> > > > I agree that data integrity issues are a higher priority than feature
> > > > development, so I also support the decision. The fact that several of
> > the
> > > > major remaining 5.2 features are currently being developed in
> > > long-running
> > > > feature branches also helps, as work can continue there at the cost
> of
> > a
> > > > rebase later.
> > > >
> > > > How does this affect 5.1.4, which is also listed as a Fix Version for
> > > > PHOENIX-7106? From the bug description it also sounds like 5.1.3 and
> > the
> > > > forthcoming .4 are affected, since we have server-side paging in 5.1.
> > > (Feel
> > > > free to move that to a separate thread if you feel it should be a
> > > separate
> > > > discussion.) Should this be a blocker for releasing 5.1.4?
> > > >
> > > > Geoffrey
> > > >
> > > >
> > > > On Wed, Jan 3, 2024 at 5:06 PM Kadir Ozdemir <
> > > > ka...@gsuite.cloud.apache.org>
> > > > wrote:
> > > >
> > > > > Being a database, Phoenix has to make sure that the data stays on
> > disk
> > > > > intact and its queries return correct data. In this case, Phoenix
> > fails
> > > > to
> > > > > return correct data for some queries if their scans experience
> region
> > > > > movement. Now that we know these data integrity issues and how to
> > > > reproduce
> > > > > them, fixing them should be our first priority. So, I fully support
> > > this
> > > > > proposal.
> > > > >
> > > > > On Wed, Jan 3, 2024 at 10:58 PM Viraj Jasani 
> > > wrote:
> > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I would like to bring PHOENIX-7106
> > > > > > <
> https://urldefense.com/v3/__https://issues.apache.org/jira/browse/PHOENIX-7106__;!!DCbAVzZNrAf4!FZG5sv55IC1NqItQLY7GKWgUG2Do0gSta01gOiSdd36Dx3XHGtQx4M3c9visVXIt9DctPQzS-orob9vhzrCfVA$
> > to everyone's
> > > > > > attention here and brief about the data integrity issues that we
> > have
> > > > in
> > > > > > various coprocessors. Majority of the issues are related to the
> > fact
> > > > that
> > > > > > we do not return valid rowkey for certain queries. If any region
> > > moves
> > > > in
> > > > > > the middle of the scan, the HBase client relies on the last
> > returned
> > > > > rowkey
> > > > > > and accordingly changes the scan boundaries while the scanner is
> > > > getting
> > > > > > reset to continue the scan operation. If the region does not
> move,
> > > scan
> > > > > is
> > > > > > not expected to return invalid data, however if the region moves
> in
> > > the
> > > > > > middle of ongoing scan operation, scan would return
> > invalid/incorrect
> > > > > data
> > > > > > causing data integrity issues.
> > > > > >
> > > > > > Given the critical nature of these issues, I would like to
> propose
> > > that
> > > > > we
> > > > > > treat this as a high priority for the upcoming 5.2.0 release, and
> > not
> > > > > > include any other feature or big change to master branch until we
> > > merge
> > > > > > this. The PR is still not ready as additional changes are still
> in
> > my
> > > > > > local, requiring rebase with the current master.
> > > > > >
> > > 

Re: [ANNOUNCE] Lokesh Khurana as Phoenix Committer

[Geoffrey Jacoby]

Congratulations, Lokesh!

On Wed, Jan 17, 2024 at 12:25 PM Viraj Jasani  wrote:

> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Lokesh
> Khurana has accepted the PMC's invitation to become a committer on Apache
> Phoenix.
>
> We appreciate all of the great contributions Lokesh has made to the
> community thus far and we look forward to his continued involvement.
>
> Congratulations and Welcome, Lokesh!
>

[ANNOUNCE] Lokesh Khurana as Phoenix Committer

[Viraj Jasani]

On behalf of the Apache Phoenix PMC, I'm pleased to announce that Lokesh
Khurana has accepted the PMC's invitation to become a committer on Apache
Phoenix.

We appreciate all of the great contributions Lokesh has made to the
community thus far and we look forward to his continued involvement.

Congratulations and Welcome, Lokesh!

[jira] [Created] (PHOENIX-7184) Teardown logic is failing for tests MutableIndexSplit*ScanIT

[Sanjeet Malhotra (Jira)]

Sanjeet Malhotra created PHOENIX-7184:
-

 Summary: Teardown logic is failing for tests 
MutableIndexSplit*ScanIT
 Key: PHOENIX-7184
 URL: https://issues.apache.org/jira/browse/PHOENIX-7184
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 5.2.0
 Environment: JDK 8 with HBase 2.5
Reporter: Sanjeet Malhotra


If ITs: MutableIndexSplitReverseScanIT and MutableIndexSplitForwardScanIT, were 
run and table count threshold defined in BaseTest class is reached for the 
minicluster then teardown logic is invoked. The teardown logic deregisters the 
Phoenix driver first followed by deleting the table. As the Phoenix Driver got 
deregistered so regions were about to be opened seemed to be stuck in 
transition and causing deletion of tables to fail.

 

Steps to reproduce error using MutableIndexSplitReverseScanIT:
 # Set `TEARDOWN_THRESHOLD` to 1 in BaseTest.
 # Run the IT and once it completes, check for following lines in failsafe 
`*-output.txt` file.
 ## 
{quote}2024-01-17T08:40:58,966 INFO [Listener at localhost/64544] 
query.BaseTest(811): Shutting down mini cluster because number of tables on 
this mini cluster is likely greater than 1{quote}
 ## 
{quote}2024-01-17T08:41:01,408 ERROR 
[RS_OPEN_REGION-regionserver/localhost:0-1] regionserver.HRegion(1155): Could 
not initialize all stores for the 
region=TBL_N07,m,1705509658950.de4279eace097e5b32211e520b666b2c.
2024-01-17T08:41:01,408 ERROR [RS_OPEN_REGION-regionserver/localhost:0-0] 
regionserver.HRegion(1155): Could not initialize all stores for the 
region=TBL_N07,e,1705509658950.aeadc0dbcdd260980ef8cffa1463c3f2.{quote}

 

Exception stacktrace:
{quote}java.io.IOException: java.io.IOException: java.io.IOException: 
java.sql.SQLException: No suitable driver found for 
jdbc:phoenix+zk:127.0.0.1\:52437::/hbase;test=true;
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1150)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeStores(HRegion.java:1093)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.HRegion.initializeRegionInternals(HRegion.java:996)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion.initialize(HRegion.java:943) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7230) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.HRegion.openHRegionFromTableDir(HRegion.java:7185)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7161) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7120) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion.openHRegion(HRegion.java:7076) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.handler.AssignRegionHandler.process(AssignRegionHandler.java:149)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.executor.EventHandler.run(EventHandler.java:104) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
~[?:1.8.0_345]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
~[?:1.8.0_345]
at java.lang.Thread.run(Thread.java:750) ~[?:1.8.0_345]
Caused by: java.io.IOException: java.io.IOException: java.sql.SQLException: No 
suitable driver found for jdbc:phoenix+zk:127.0.0.1\:52437::/hbase;test=true;
at 
org.apache.hadoop.hbase.regionserver.StoreEngine.openStoreFiles(StoreEngine.java:288)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.StoreEngine.initialize(StoreEngine.java:338)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HStore.(HStore.java:297) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at 
org.apache.hadoop.hbase.regionserver.HRegion.instantiateHStore(HRegion.java:6361)
 ~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1116) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at org.apache.hadoop.hbase.regionserver.HRegion$1.call(HRegion.java:1113) 
~[hbase-server-2.5.5-hadoop3.jar:2.5.5-hadoop3]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_345]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
~[?:1.8.0_345]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_345]
... 3 more{quote}
 

If we call deregister Driver after deleting all the tables then we run into 
cyclic dependency where implementation of CQSI for test setup calls 

Re: [VOTE] Release of Apache Phoenix Omid 1.1.1 RC0

[Richárd Antal]

-1

Signature: OK
Checksum: OK
mvn clean apache-rat:check: OK

Changes and release notes: OK

Built from source (1.8.0_241): OK
  - mvn clean install  -DskipTests
Ran tests on my MacBook locally:
  - mvn clean verify : Failed
TestTSOClientConnectionToTSO had failing tests:
testSuccessfulConnectionToTSOThroughZK and
testSuccessOfTSOClientReconnectionsToARestartedTSOWithZKPublishing
It might be because it uses IPv6
Some logs

2024-01-17T15:17:45,858 INFO
>  [TestNGInvoker-testSuccessfulConnectionToTSOThroughZK()] client.TSOClient:
> * Current TSO host:port found in ZK:
> [fe80:0:0:0:aede:48ff:fe00:1122%en5]:52934 Epoch 0
> 2024-01-17T15:17:45,859 INFO  [tsofsm-0] client.TSOClient: Trying to
> connect to TSO [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934]
> 2024-01-17T15:17:45,863 ERROR [tsoclient-worker-0] client.TSOClient:
> Failed connection attempt to TSO
> [/fe80:0:0:0:aede:48ff:fe00:1122%en5:52934] failed. Channel [id: 0x9d8c0b44]


I’ve also tested the TestTSOClientConnectionToTSO on the 1.1.0 release
locally and that was successful (It used IPv4).
I think this is a regression on Mac and it would be nice to fix before the
release.

Richard

Cong Luo  ezt írta (időpont: 2024. jan. 11., Cs, 3:52):

> +1
>
> I did a basic test last month in the test environment (fully distributed)
> based on phoenix 5.1.3 + omid 1.1.1 and did not find a blocking issue.
>
> On 2024/01/09 12:53:28 "rajeshb...@apache.org" wrote:
> > Please vote on this Apache phoenix omid release candidate,
> > phoenix-omid-1.1.1RC0
> >
> > The VOTE will remain open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache phoenix omid 1.1.1
> > [ ] -1 Do not release this package because ...
> >
> > The tag to be voted on is 1.1.1RC0:
> >
> >   https://github.com/apache/phoenix-omid/tree/1.1.1RC0
> >
> > 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-omid-1.1.1RC0/
> >
> > Maven artifacts are available in a staging repository at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachephoenix-1251/
> >
> > 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 omid, please see
> >
> >   https://phoenix.apache.org/
> >
> > Thanks,
> > Rajeshbabu.
> >
>

[jira] [Created] (PHOENIX-7183) Upgrade jackson to 2.15.0

[Jira]

Richárd Antal created PHOENIX-7183:
--

 Summary: Upgrade jackson to 2.15.0
 Key: PHOENIX-7183
 URL: https://issues.apache.org/jira/browse/PHOENIX-7183
 Project: Phoenix
  Issue Type: Task
Reporter: Richárd Antal






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

[jira] [Updated] (PHOENIX-7129) Use Newer Maven for Connectors ASF CI

[Istvan Toth (Jira)]

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

Istvan Toth updated PHOENIX-7129:
-
Priority: Major  (was: Minor)

> Use Newer Maven for Connectors ASF CI
> -
>
> Key: PHOENIX-7129
> URL: https://issues.apache.org/jira/browse/PHOENIX-7129
> Project: Phoenix
>  Issue Type: Bug
>  Components: connectors
>Reporter: Istvan Toth
>Priority: Major
>  Labels: test
>
> The test fails because it picks up maven 3.3.9.
> Figure out how to use a newer maven.



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

[jira] [Assigned] (PHOENIX-7129) Use Newer Maven for Connectors ASF CI

[Istvan Toth (Jira)]

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

Istvan Toth reassigned PHOENIX-7129:


Assignee: (was: Istvan Toth)

> Use Newer Maven for Connectors ASF CI
> -
>
> Key: PHOENIX-7129
> URL: https://issues.apache.org/jira/browse/PHOENIX-7129
> Project: Phoenix
>  Issue Type: Bug
>  Components: connectors
>Reporter: Istvan Toth
>Priority: Minor
>  Labels: test
>
> The test fails because it picks up maven 3.3.9.
> Figure out how to use a newer maven.



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

[jira] [Updated] (PHOENIX-7182) Update Curator to 4.2 on the 5.1 branch

[Istvan Toth (Jira)]

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

Istvan Toth updated PHOENIX-7182:
-
Summary: Update Curator to 4.2 on the 5.1 branch  (was: Update Curator to 
4.2 on 5.1 branch)

> Update Curator to 4.2 on the 5.1 branch
> ---
>
> Key: PHOENIX-7182
> URL: https://issues.apache.org/jira/browse/PHOENIX-7182
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.1.4
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Minor
>
> 4.2 is the latest version that is compatible with ZK 3.4.x., and master 
> already uses that.



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

[jira] [Updated] (PHOENIX-7182) Update Curator to 4.2 on 5.1 branch

[Istvan Toth (Jira)]

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

Istvan Toth updated PHOENIX-7182:
-
Priority: Minor  (was: Major)

> Update Curator to 4.2 on 5.1 branch
> ---
>
> Key: PHOENIX-7182
> URL: https://issues.apache.org/jira/browse/PHOENIX-7182
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.1.4
>Reporter: Istvan Toth
>Priority: Minor
>
> 4.2 is the latest version that is compatible with ZK 3.4.x., and master 
> already uses that.



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

[jira] [Assigned] (PHOENIX-7182) Update Curator to 4.2 on 5.1 branch

[Istvan Toth (Jira)]

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

Istvan Toth reassigned PHOENIX-7182:


Assignee: Istvan Toth

> Update Curator to 4.2 on 5.1 branch
> ---
>
> Key: PHOENIX-7182
> URL: https://issues.apache.org/jira/browse/PHOENIX-7182
> Project: Phoenix
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 5.1.4
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Minor
>
> 4.2 is the latest version that is compatible with ZK 3.4.x., and master 
> already uses that.



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

[jira] [Created] (PHOENIX-7182) Update Curator to 4.2 on 5.1 branch

[Istvan Toth (Jira)]

Istvan Toth created PHOENIX-7182:


 Summary: Update Curator to 4.2 on 5.1 branch
 Key: PHOENIX-7182
 URL: https://issues.apache.org/jira/browse/PHOENIX-7182
 Project: Phoenix
  Issue Type: Improvement
  Components: core
Affects Versions: 5.1.4
Reporter: Istvan Toth


4.2 is the latest version that is compatible with ZK 3.4.x., and master already 
uses that.




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