Re: [ANNOUNCE] New Phoenix committer: Ohad Shacham
Congrats Ohad, well deserved! On Tue, Jun 12, 2018 at 11:48 AM, Geoffrey Jacoby wrote: > Congrats, Ohad! Looking forward to seeing the new transaction framework. > > On Mon, Jun 11, 2018 at 7:09 PM, James Taylor > wrote: > > > On behalf of the Apache Phoenix PMC, I'm please to announce that Ohad > > Shacham has accepted our invitation to become a committer. He's been > > diligently working on integrating the Apache Omid transaction engine [1] > > with Phoenix, both by enhancing Omid and by generalizing the transaction > > interface in Phoenix [2]. > > > > Please give Ohad a warm welcome to the team! > > > > James > > > > [1] https://omid.incubator.apache.org/ > > [2] > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a= > > shortlog;h=refs/heads/omid2 > > >
Re: [ANNOUNCE] New Phoenix PMC member: Vincent Poon
Congrats Vincent, looking forward to more excellent work. On Tue, Jun 12, 2018 at 11:44 AM, Geoffrey Jacoby wrote: > Congratulations, Vincent! Thanks for all your hard work on indexes. > > On Mon, Jun 11, 2018 at 7:20 PM, James Taylor > wrote: > > > On behalf of the Apache Phoenix PMC, I'm please to announce that Vincent > > Poon has accepted our invitation to join the PMC. He's been focused on > > improving the stability and performance of secondary indexing over the > last > > several releases. > > > > Please congratulate Vincent on the fantastic job he's doing. > > > > Thanks, > > James > > >
Re: [ANNOUNCE] New Phoenix PMC member: Pedro Boado
Congrats Pedro! On Tue, Jun 12, 2018 at 11:47 AM, Geoffrey Jacoby wrote: > Congrats, Pedro! > > On Mon, Jun 11, 2018 at 7:15 PM, James Taylor > wrote: > > > On behalf of the Apache Phoenix PMC, I'm please to announce that Pedro > > Boado has accepted our invitation to join the PMC. He's been the force > > behind our recent support for CDH (and the reason we have support not > only > > for CDH 5.11 in our 4.14 release, but 5.12, 5.13, and 5.14 as well). > > > > Please congratulate Pedro on the excellent work he's doing. > > > > James > > >
Re: [DISCUSS] stop minor releases for 0.98 and 1.1
+1 on reducing the number of branches. On Tue, Jun 12, 2018 at 2:03 PM, Vincent Poon wrote: > big +1 > Commits have been way too burdensome > > On Tue, Jun 12, 2018 at 9:08 AM, Josh Elser wrote: > > > Also +1 > > > > Do that after the release? Or before? > > > > > > On 6/12/18 11:55 AM, James Taylor wrote: > > > >> Somewhat orthogonal, but we should move master to a new 4.x-HBase-1.4 > >> branch and make 5.x the master branch. > >> > >> On Tue, Jun 12, 2018 at 8:31 AM Josh Elser wrote: > >> > >> +1 > >>> > >>> I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, but > >>> I might be inventing that). I'm also not so sure about the value behind > >>> a 1.3 release either (I think Andrew's 1.4 branch is much more > relevant). > >>> > >>> Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, > we > >>> can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro wants > >>> to support. > >>> > >>> On 6/11/18 9:47 PM, James Taylor wrote: > >>> > It feels like we're trying to maintain too many branches. Both HBase > 0.98 > and 1.1 have been EOLed. To ease the burden on devs, how about we stop > maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can > > >>> always > >>> > step up if need be to do a patch release from the 4.14 branches. > > Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, do > we > need the 4.x-HBase-1.2 branch? > > It'd be good if this was decided prior to the biggish splittable > system > catalog work (PHOENIX-3534) and omid transaction integration > > >>> (PHOENIX-3623). > >>> > > Thanks, > James > > > >>> > >> >
[jira] [Commented] (PHOENIX-4195) PHOENIX-4195 Deleting view rows with extended PKs through the base table silently fails
[ https://issues.apache.org/jira/browse/PHOENIX-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510336#comment-16510336 ] Thomas D'Silva commented on PHOENIX-4195: - I think we have to disable all mutations using a global connection to any table that has child views. The tenant or global connection would have to create the view first and then create the view index. Once the view is created whenever the base table is resolved (by making a call to the server) to fetch the latest metadata the basetable PTable would have the hasChildViews flag set to true. Index creation should be able to handle any in-progress mutations queued on the region because we run a second index population catch up query. See PHOENIX-2582 on details of how to improve this. We need the hasChildViews to prevent issues while creating global views on non multi-tenant tables. > PHOENIX-4195 Deleting view rows with extended PKs through the base table > silently fails > --- > > Key: PHOENIX-4195 > URL: https://issues.apache.org/jira/browse/PHOENIX-4195 > Project: Phoenix > Issue Type: Bug >Reporter: Thomas D'Silva >Assignee: Geoffrey Jacoby >Priority: Major > Attachments: test.diff > > > The attached test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4195) PHOENIX-4195 Deleting view rows with extended PKs through the base table silently fails
[ https://issues.apache.org/jira/browse/PHOENIX-4195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510321#comment-16510321 ] Geoffrey Jacoby commented on PHOENIX-4195: -- [~jamestaylor] - if the intention is to make it impossible to corrupt a view index, wouldn't you have to disable both UPSERTs and DELETEs to any multi-tenant table from any global connection? Even if you had a hasChildViews boolean in PTable, any global connection write would have a potential race condition if another tenant-connection was trying to create a view + view index, wouldn't it? >From a usability standpoint, however, that would be problematic, because there >are many important use cases in which most users access a multi-tenant table >through tenant connections, but bulk or admin operations are done cross-tenant >by global connections. And even if we do disable writes from global connections to multi-tenant tables, isn't there still a race condition where another client could be creating a _global_ view on a non-multi-tenant table that would cause problems when deleting or mutating the base table? > PHOENIX-4195 Deleting view rows with extended PKs through the base table > silently fails > --- > > Key: PHOENIX-4195 > URL: https://issues.apache.org/jira/browse/PHOENIX-4195 > Project: Phoenix > Issue Type: Bug >Reporter: Thomas D'Silva >Assignee: Geoffrey Jacoby >Priority: Major > Attachments: test.diff > > > The attached test fails. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4780) HTable.batch() doesn't handle TableNotFound correctly.
[
https://issues.apache.org/jira/browse/PHOENIX-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510300#comment-16510300
]
Xu Cang commented on PHOENIX-4780:
--
same this I think: https://issues.apache.org/jira/browse/HBASE-20621
> HTable.batch() doesn't handle TableNotFound correctly.
> --
>
> Key: PHOENIX-4780
> URL: https://issues.apache.org/jira/browse/PHOENIX-4780
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>Priority: Minor
>
> batch() as well as delete() are processing using AsyncRequest. To report
> about problems we are using RetriesExhaustedWithDetailsException and there is
> no special handling for TableNotFound exception. So, the final result for
> running batch or delete operations against not existing table looks really
> weird and missleading:
> {noformat}
> hbase(main):003:0> delete 't1', 'r1', 'c1'
> 2018-06-12 15:02:50,742 ERROR [main] client.AsyncRequestFutureImpl: Cannot
> get replica 0 location for
> {"totalColumns":1,"row":"r1","families":{"c1":[{"qualifier":"","vlen":0,"tag":[],"timestamp":9223372036854775807}]},"ts":9223372036854775807}
> ERROR: Failed 1 action: t1: 1 time, servers with issues: null
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (PHOENIX-4780) HTable.batch() doesn't handle TableNotFound correctly.
[
https://issues.apache.org/jira/browse/PHOENIX-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Soldatov resolved PHOENIX-4780.
--
Resolution: Invalid
Oops. wrong project :)
> HTable.batch() doesn't handle TableNotFound correctly.
> --
>
> Key: PHOENIX-4780
> URL: https://issues.apache.org/jira/browse/PHOENIX-4780
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Sergey Soldatov
>Assignee: Sergey Soldatov
>Priority: Minor
>
> batch() as well as delete() are processing using AsyncRequest. To report
> about problems we are using RetriesExhaustedWithDetailsException and there is
> no special handling for TableNotFound exception. So, the final result for
> running batch or delete operations against not existing table looks really
> weird and missleading:
> {noformat}
> hbase(main):003:0> delete 't1', 'r1', 'c1'
> 2018-06-12 15:02:50,742 ERROR [main] client.AsyncRequestFutureImpl: Cannot
> get replica 0 location for
> {"totalColumns":1,"row":"r1","families":{"c1":[{"qualifier":"","vlen":0,"tag":[],"timestamp":9223372036854775807}]},"ts":9223372036854775807}
> ERROR: Failed 1 action: t1: 1 time, servers with issues: null
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-4780) HTable.batch() doesn't handle TableNotFound correctly.
Sergey Soldatov created PHOENIX-4780:
Summary: HTable.batch() doesn't handle TableNotFound correctly.
Key: PHOENIX-4780
URL: https://issues.apache.org/jira/browse/PHOENIX-4780
Project: Phoenix
Issue Type: Bug
Affects Versions: 2.2.0
Reporter: Sergey Soldatov
Assignee: Sergey Soldatov
batch() as well as delete() are processing using AsyncRequest. To report about
problems we are using RetriesExhaustedWithDetailsException and there is no
special handling for TableNotFound exception. So, the final result for running
batch or delete operations against not existing table looks really weird and
missleading:
{noformat}
hbase(main):003:0> delete 't1', 'r1', 'c1'
2018-06-12 15:02:50,742 ERROR [main] client.AsyncRequestFutureImpl: Cannot get
replica 0 location for
{"totalColumns":1,"row":"r1","families":{"c1":[{"qualifier":"","vlen":0,"tag":[],"timestamp":9223372036854775807}]},"ts":9223372036854775807}
ERROR: Failed 1 action: t1: 1 time, servers with issues: null
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (PHOENIX-4755) Provide an option to plugin custom avatica server config in PQS
[
https://issues.apache.org/jira/browse/PHOENIX-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510265#comment-16510265
]
Josh Elser commented on PHOENIX-4755:
-
Ok at a glance, [~karanmehta93].
My only suggestion would be to take a fresh look at how we're using these
Avatica APIs inside PQS. We only have "no auth" and "SPNEGO" auth presently. We
might be able to do a better job inside of PQS by refactoring how we enable
this stuff.
> Provide an option to plugin custom avatica server config in PQS
> ---
>
> Key: PHOENIX-4755
> URL: https://issues.apache.org/jira/browse/PHOENIX-4755
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4755.001.diff
>
>
> CALCITE-2294 Allow customization for {{AvaticaServerConfiguration}} for
> plugging new authentication mechanisms
> Add a new Phoenix level property and provide resolve the class using
> {{InstanceResolver}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] stop minor releases for 0.98 and 1.1
big +1 Commits have been way too burdensome On Tue, Jun 12, 2018 at 9:08 AM, Josh Elser wrote: > Also +1 > > Do that after the release? Or before? > > > On 6/12/18 11:55 AM, James Taylor wrote: > >> Somewhat orthogonal, but we should move master to a new 4.x-HBase-1.4 >> branch and make 5.x the master branch. >> >> On Tue, Jun 12, 2018 at 8:31 AM Josh Elser wrote: >> >> +1 >>> >>> I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, but >>> I might be inventing that). I'm also not so sure about the value behind >>> a 1.3 release either (I think Andrew's 1.4 branch is much more relevant). >>> >>> Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, we >>> can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro wants >>> to support. >>> >>> On 6/11/18 9:47 PM, James Taylor wrote: >>> It feels like we're trying to maintain too many branches. Both HBase 0.98 and 1.1 have been EOLed. To ease the burden on devs, how about we stop maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can >>> always >>> step up if need be to do a patch release from the 4.14 branches. Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, do we need the 4.x-HBase-1.2 branch? It'd be good if this was decided prior to the biggish splittable system catalog work (PHOENIX-3534) and omid transaction integration >>> (PHOENIX-3623). >>> Thanks, James >>> >>
[jira] [Commented] (PHOENIX-4755) Provide an option to plugin custom avatica server config in PQS
[
https://issues.apache.org/jira/browse/PHOENIX-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510031#comment-16510031
]
Karan Mehta commented on PHOENIX-4755:
--
[~alexaraujo] [~elserj]
Thoughts on this patch?
> Provide an option to plugin custom avatica server config in PQS
> ---
>
> Key: PHOENIX-4755
> URL: https://issues.apache.org/jira/browse/PHOENIX-4755
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4755.001.diff
>
>
> CALCITE-2294 Allow customization for {{AvaticaServerConfiguration}} for
> plugging new authentication mechanisms
> Add a new Phoenix level property and provide resolve the class using
> {{InstanceResolver}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4755) Provide an option to plugin custom avatica server config in PQS
[
https://issues.apache.org/jira/browse/PHOENIX-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karan Mehta updated PHOENIX-4755:
-
Attachment: PHOENIX-4755.001.diff
> Provide an option to plugin custom avatica server config in PQS
> ---
>
> Key: PHOENIX-4755
> URL: https://issues.apache.org/jira/browse/PHOENIX-4755
> Project: Phoenix
> Issue Type: Improvement
>Reporter: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4755.001.diff
>
>
> CALCITE-2294 Allow customization for {{AvaticaServerConfiguration}} for
> plugging new authentication mechanisms
> Add a new Phoenix level property and provide resolve the class using
> {{InstanceResolver}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [ANNOUNCE] New Phoenix committer: Ohad Shacham
Congrats, Ohad! Looking forward to seeing the new transaction framework. On Mon, Jun 11, 2018 at 7:09 PM, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm please to announce that Ohad > Shacham has accepted our invitation to become a committer. He's been > diligently working on integrating the Apache Omid transaction engine [1] > with Phoenix, both by enhancing Omid and by generalizing the transaction > interface in Phoenix [2]. > > Please give Ohad a warm welcome to the team! > > James > > [1] https://omid.incubator.apache.org/ > [2] > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a= > shortlog;h=refs/heads/omid2 >
Re: [ANNOUNCE] New Phoenix PMC member: Pedro Boado
Congrats, Pedro! On Mon, Jun 11, 2018 at 7:15 PM, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm please to announce that Pedro > Boado has accepted our invitation to join the PMC. He's been the force > behind our recent support for CDH (and the reason we have support not only > for CDH 5.11 in our 4.14 release, but 5.12, 5.13, and 5.14 as well). > > Please congratulate Pedro on the excellent work he's doing. > > James >
Re: [ANNOUNCE] New Phoenix PMC member: Vincent Poon
Congratulations, Vincent! Thanks for all your hard work on indexes. On Mon, Jun 11, 2018 at 7:20 PM, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm please to announce that Vincent > Poon has accepted our invitation to join the PMC. He's been focused on > improving the stability and performance of secondary indexing over the last > several releases. > > Please congratulate Vincent on the fantastic job he's doing. > > Thanks, > James >
Re: [ANNOUNCE] New Phoenix PMC member: Vincent Poon
Congrats Vincent!!! On Tue, Jun 12, 2018 at 10:15 AM, Karan Mehta wrote: > Awesome Vincent, Congrats!! > > On Mon, Jun 11, 2018 at 7:20 PM James Taylor > wrote: > > > On behalf of the Apache Phoenix PMC, I'm please to announce that Vincent > > Poon has accepted our invitation to join the PMC. He's been focused on > > improving the stability and performance of secondary indexing over the > last > > several releases. > > > > Please congratulate Vincent on the fantastic job he's doing. > > > > Thanks, > > James > > >
Re: [ANNOUNCE] New Phoenix PMC member: Vincent Poon
Awesome Vincent, Congrats!! On Mon, Jun 11, 2018 at 7:20 PM James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm please to announce that Vincent > Poon has accepted our invitation to join the PMC. He's been focused on > improving the stability and performance of secondary indexing over the last > several releases. > > Please congratulate Vincent on the fantastic job he's doing. > > Thanks, > James >
Re: [DISCUSS] stop minor releases for 0.98 and 1.1
Also +1 Do that after the release? Or before? On 6/12/18 11:55 AM, James Taylor wrote: Somewhat orthogonal, but we should move master to a new 4.x-HBase-1.4 branch and make 5.x the master branch. On Tue, Jun 12, 2018 at 8:31 AM Josh Elser wrote: +1 I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, but I might be inventing that). I'm also not so sure about the value behind a 1.3 release either (I think Andrew's 1.4 branch is much more relevant). Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, we can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro wants to support. On 6/11/18 9:47 PM, James Taylor wrote: It feels like we're trying to maintain too many branches. Both HBase 0.98 and 1.1 have been EOLed. To ease the burden on devs, how about we stop maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can always step up if need be to do a patch release from the 4.14 branches. Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, do we need the 4.x-HBase-1.2 branch? It'd be good if this was decided prior to the biggish splittable system catalog work (PHOENIX-3534) and omid transaction integration (PHOENIX-3623). Thanks, James
Re: [DISCUSS] stop minor releases for 0.98 and 1.1
Somewhat orthogonal, but we should move master to a new 4.x-HBase-1.4 branch and make 5.x the master branch. On Tue, Jun 12, 2018 at 8:31 AM Josh Elser wrote: > +1 > > I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, but > I might be inventing that). I'm also not so sure about the value behind > a 1.3 release either (I think Andrew's 1.4 branch is much more relevant). > > Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, we > can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro wants > to support. > > On 6/11/18 9:47 PM, James Taylor wrote: > > It feels like we're trying to maintain too many branches. Both HBase 0.98 > > and 1.1 have been EOLed. To ease the burden on devs, how about we stop > > maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can > always > > step up if need be to do a patch release from the 4.14 branches. > > > > Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, do we > > need the 4.x-HBase-1.2 branch? > > > > It'd be good if this was decided prior to the biggish splittable system > > catalog work (PHOENIX-3534) and omid transaction integration > (PHOENIX-3623). > > > > Thanks, > > James > > >
Re: [DISCUSS] stop minor releases for 0.98 and 1.1
+1 I think HBase 1.2 is soon to be dropped as well (maybe after 1.2.7, but I might be inventing that). I'm also not so sure about the value behind a 1.3 release either (I think Andrew's 1.4 branch is much more relevant). Getting to and HBase 1.4 and HBase 2.x sounds ideal to me (hopefully, we can avoid a 2.0 and 2.1 schism...), and whatever CDH stuff Pedro wants to support. On 6/11/18 9:47 PM, James Taylor wrote: It feels like we're trying to maintain too many branches. Both HBase 0.98 and 1.1 have been EOLed. To ease the burden on devs, how about we stop maintaining the 4.x-HBase-0.98 and 4.x-HBase-1.1 branches? An RM can always step up if need be to do a patch release from the 4.14 branches. Also, how about the 1.2 branch? If we kept the 4.x-cdh5.11 branch, do we need the 4.x-HBase-1.2 branch? It'd be good if this was decided prior to the biggish splittable system catalog work (PHOENIX-3534) and omid transaction integration (PHOENIX-3623). Thanks, James
