[jira] [Assigned] (PHOENIX-6291) Change Presto connector link to Trino link

[Vincent Poon (Jira)]

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

Vincent Poon reassigned PHOENIX-6291:
-

Assignee: Vincent Poon

> Change Presto connector link to Trino link
> --
>
> Key: PHOENIX-6291
> URL: https://issues.apache.org/jira/browse/PHOENIX-6291
> Project: Phoenix
>  Issue Type: Task
>    Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Trivial
> Attachments: PHOENIX-6291-trino.diff
>
>
> Presto SQL has been 
> [renamed|https://trino.io/blog/2020/12/27/announcing-trino.html] to Trino.
> This updates the Presto Phoenix connector link on the website to point to 
> Trino.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-6291) Change Presto connector link to Trino link

[Vincent Poon (Jira)]

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

Vincent Poon updated PHOENIX-6291:
--
Attachment: PHOENIX-6291-trino.diff

> Change Presto connector link to Trino link
> --
>
> Key: PHOENIX-6291
> URL: https://issues.apache.org/jira/browse/PHOENIX-6291
> Project: Phoenix
>  Issue Type: Task
>    Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Trivial
> Attachments: PHOENIX-6291-trino.diff
>
>
> Presto SQL has been 
> [renamed|https://trino.io/blog/2020/12/27/announcing-trino.html] to Trino.
> This updates the Presto Phoenix connector link on the website to point to 
> Trino.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-6291) Change Presto connector link to Trino link

[Vincent Poon (Jira)]

Vincent Poon created PHOENIX-6291:
-

 Summary: Change Presto connector link to Trino link
 Key: PHOENIX-6291
 URL: https://issues.apache.org/jira/browse/PHOENIX-6291
 Project: Phoenix
  Issue Type: Task
Reporter: Vincent Poon


Presto SQL has been 
[renamed|https://trino.io/blog/2020/12/27/announcing-trino.html] to Trino.
This updates the Presto Phoenix connector link on the website to point to Trino.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (PHOENIX-5819) Remove unused presto-phoenix-shaded connector module

[Vincent Poon (Jira)]

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

Vincent Poon updated PHOENIX-5819:
--
Attachment: PHOENIX-5819.master.v1.patch

> Remove unused presto-phoenix-shaded connector module
> 
>
> Key: PHOENIX-5819
> URL: https://issues.apache.org/jira/browse/PHOENIX-5819
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.16.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5819.master.v1.patch
>
>
> No longer needed, as Presto is using the embedded classifier in 
> phoenix-client instead



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5819) Remove unused presto-phoenix-shaded connector module

[Vincent Poon (Jira)]

Vincent Poon created PHOENIX-5819:
-

 Summary: Remove unused presto-phoenix-shaded connector module
 Key: PHOENIX-5819
 URL: https://issues.apache.org/jira/browse/PHOENIX-5819
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.16.0
Reporter: Vincent Poon
Assignee: Vincent Poon


No longer needed, as Presto is using the embedded classifier in phoenix-client 
instead



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (PHOENIX-5620) Phoenix-client embedded do not shade properly slf4j classes

[Vincent Poon (Jira)]

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

Vincent Poon reassigned PHOENIX-5620:
-

Assignee: Vincent Poon

> Phoenix-client embedded do not shade properly slf4j classes
> ---
>
> Key: PHOENIX-5620
> URL: https://issues.apache.org/jira/browse/PHOENIX-5620
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Grzegorz Kokosinski
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5620.4.x-HBase-1.4.v1.patch
>
>
> Phoenix-client should either shade slf4j or require slf4j dependency. Now 
> projects that are using slf4j internally conflicts with phoenix-client embeded
> $ unzip -l 
> ~/.m2/repository/org/apache/phoenix/phoenix-client/4.14.1-HBase-1.4/phoenix-client-4.14.1-HBase-1.4-embedded.jar
>  | grep slf4j
>  0 04-12-2019 13:18 org/slf4j/
>  0 04-12-2019 13:18 org/slf4j/helpers/
>  3366 04-12-2019 13:18 org/slf4j/helpers/BasicMarker.class
>  1427 04-12-2019 13:18 org/slf4j/helpers/BasicMarkerFactory.class
>  2660 04-12-2019 13:18 org/slf4j/helpers/BasicMDCAdapter.class
>  1521 04-12-2019 13:18 org/slf4j/helpers/FormattingTuple.class
>  4704 04-12-2019 13:18 org/slf4j/helpers/MarkerIgnoringBase.class
>  6607 04-12-2019 13:18 org/slf4j/helpers/MessageFormatter.class
>  823 04-12-2019 13:18 org/slf4j/helpers/NamedLoggerBase.class
>  3267 04-12-2019 13:18 org/slf4j/helpers/NOPLogger.class
>  584 04-12-2019 13:18 org/slf4j/helpers/NOPLoggerFactory.class
>  1005 04-12-2019 13:18 org/slf4j/helpers/NOPMDCAdapter.class
>  1047 04-12-2019 13:18 org/slf4j/helpers/SubstituteLoggerFactory.class
>  931 04-12-2019 13:18 org/slf4j/helpers/Util.class
>  180 04-12-2019 13:18 org/slf4j/ILoggerFactory.class
>  272 04-12-2019 13:18 org/slf4j/IMarkerFactory.class
>  1375 04-12-2019 13:18 org/slf4j/Logger.class
>  7940 04-12-2019 13:18 org/slf4j/LoggerFactory.class
>  601 04-12-2019 13:18 org/slf4j/Marker.class
>  1325 04-12-2019 13:18 org/slf4j/MarkerFactory.class
>  2807 04-12-2019 13:18 org/slf4j/MDC.class
>  0 04-12-2019 13:18 org/slf4j/spi/
>  455 04-12-2019 13:18 org/slf4j/spi/LocationAwareLogger.class
>  249 04-12-2019 13:18 org/slf4j/spi/LoggerFactoryBinder.class
>  249 04-12-2019 13:18 org/slf4j/spi/MarkerFactoryBinder.class
>  384 04-12-2019 13:18 org/slf4j/spi/MDCAdapter.class
>  0 04-12-2019 13:18 META-INF/maven/org.slf4j/
>  0 04-12-2019 13:18 META-INF/maven/org.slf4j/slf4j-api/
>  2689 04-12-2019 13:18 META-INF/maven/org.slf4j/slf4j-api/pom.xml
>  108 04-12-2019 13:18 META-INF/maven/org.slf4j/slf4j-api/pom.properties
> Maven complains:
> [WARNING] Found duplicate and different classes in 
> [org.apache.phoenix:phoenix-client:4.14.1-HBase-1.4:jar:embedded, 
> org.slf4j:slf4j-api:1.7.28]:
> [WARNING] org.slf4j.ILoggerFactory
> [WARNING] org.slf4j.IMarkerFactory
> [WARNING] org.slf4j.Logger
> [WARNING] org.slf4j.LoggerFactory
> [WARNING] org.slf4j.MDC
> [WARNING] org.slf4j.Marker
> [WARNING] org.slf4j.MarkerFactory
> [WARNING] org.slf4j.helpers.BasicMDCAdapter
> [WARNING] org.slf4j.helpers.BasicMarker
> [WARNING] org.slf4j.helpers.BasicMarkerFactory
> [WARNING] org.slf4j.helpers.FormattingTuple
> [WARNING] org.slf4j.helpers.MarkerIgnoringBase
> [WARNING] org.slf4j.helpers.MessageFormatter
> [WARNING] org.slf4j.helpers.NOPLogger
> [WARNING] org.slf4j.helpers.NOPLoggerFactory
> [WARNING] org.slf4j.helpers.NOPMDCAdapter
> [WARNING] org.slf4j.helpers.NamedLoggerBase
> [WARNING] org.slf4j.helpers.SubstituteLoggerFactory
> [WARNING] org.slf4j.helpers.Util
> [WARNING] org.slf4j.spi.LocationAwareLogger
> [WARNING] org.slf4j.spi.LoggerFactoryBinder
> [WARNING] org.slf4j.spi.MDCAdapter
> [WARNING] org.slf4j.spi.MarkerFactoryBinder



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] Release of Apache Phoenix 4.15.0 RC1

[Vincent Poon]

+1 (Binding)

Did some sanity testing with old client and new server.  Creating tables,
global/local indexes, etc.  all seemed fine.

On Thu, Nov 21, 2019 at 12:58 PM la...@apache.org  wrote:

>  I agree that PHOENIX-5529 and PHOENIX-5580 are longstanding issues and
> not blockers for 4.15.0. My +1 stands.
> Other PCMs, please vote so that we can (finally) get a 4.15.0 release out.
> Cheers.
> -- Lars
>
> On Wednesday, November 20, 2019, 7:23:01 PM PST, Chinmay Kulkarni <
> chinmayskulka...@gmail.com> wrote:
>
>  +1 (Binding)
>
> - Built from source (4.15.0-HBase-1.3) : OK
> - mvn verify : OK
> - Did some basic DDL, upserts, deletes, querying, and everything looked
> fine : OK
> (Note, I found PHOENIX-5529
>  and PHOENIX-5580
>  during my testing,
> but
> these bugs are also present in 4.14.x and hence not blockers for 4.15.0)
> - Verified checksums : OK
> - Verified signatures : OK
> - mvn clean apache-rat:check : OK
>
> On Wed, Nov 20, 2019 at 10:34 AM Chinmay Kulkarni <
> chinmayskulka...@gmail.com> wrote:
>
> > *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC1*
> >
> > Just sending out a friendly reminder to everyone to please vote on Apache
> > Phoenix 4.15.0 RC1 (thanks Lars).
> >
> > On Tue, Nov 19, 2019 at 2:49 PM la...@apache.org 
> wrote:
> >
> >>  I responded yesterday, but somehow didn't appear to go through. Trying
> >> again...
> >>
> >> +1 (Binding)
> >>
> >> - built from source (4.x-HBase-1.5) with latest branch-1 HBase (also
> >> built from source)
> >> - loaded a few million rows
> >> - tried with local indexes
> >> - issued upserts and deletes while splitting in HBase.
> >> - checked the test suite on Jenkins :)
> >> - all good
> >> - nothing undue in the logs
> >>
> >> -- Lars
> >>
> >>On Monday, November 18, 2019, 02:57:59 PM PST, Chinmay Kulkarni <
> >> chinmayskulka...@gmail.com> wrote:
> >>
> >>  Hello Everyone,
> >>
> >> This is a call for a vote on Apache Phoenix 4.15.0 RC1. This is the next
> >> minor release of Phoenix 4, compatible with Apache HBase 1.3, 1.4, &
> >> 1.5. The release includes both a source-only release and a convenience
> >> binary release for each supported HBase version.
> >>
> >> This release has feature parity with supported HBase versions and
> includes
> >> the following improvements:
> >> - Support for multi-region SYSTEM.CATALOG
> >> - Omid integration with Phoenix
> >> - Orphan view tool
> >> - Separation of the Phoenix-Connectors and Phoenix-Queryserver projects
> >> - 150+ bug fixes
> >> and much more
> >>
> >> The source tarball, including signatures, digests, etc can be found at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.3-rc1/src/
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.4-rc1/src/
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.5-rc1/src/
> >>
> >> The binary artifacts can be found at:
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.3-rc1/bin/
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.4-rc1/bin/
> >>
> >>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.5-rc1/bin/
> >>
> >> For a complete list of changes, see:
> >>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12343162
> >>
> >> Artifacts are signed with my "CODE SIGNING KEY":
> >> 7C5FC713DE4C59D7
> >>
> >> KEYS file available here:
> >> https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> >>
> >> The hash and tag to be voted upon:
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=a9491b4339ceef1c09922c752147fd97068039cd
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.15.0-HBase-1.3-rc1
> >>
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=f95b1937af1a525c2bf49e0a50bf73fce09a5314
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.15.0-HBase-1.4-rc1
> >>
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=241a3284cf9128a08d0db49d07c2cfecceeada06
> >>
> >>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.15.0-HBase-1.5-rc1
> >>
> >> Vote will be open for at least 72 hours. Please vote:
> >>
> >> [ ] +1 approve
> >> [ ] +0 no opinion
> >> [ ] -1 disapprove (and reason why)
> >>
> >> Thanks,
> >> The Apache Phoenix Team
> >>
> >> --
> >> Chinmay Kulkarni
> >>
> >
> > --
> > Chinmay Kulkarni
> >
>
>
> --
> Chinmay Kulkarni
>

Re: question about Presto on Phoenix.

[Vincent Poon]

Not sure if you're the same person, but there is an issue open
https://github.com/prestosql/presto/issues/1271
Unfortunately, I've been pretty busy lately and haven't had time to try any
newer versions.
If you want to try yourself, you could start by building the phoenix-client
'embedded' classifier , and try using that in presto-phoenix

On Sun, Nov 3, 2019 at 9:14 PM 18457090494 <18457090...@163.com> wrote:

> Hello, I'm a developer. I want to ask you a question about Presto on
> Phoenix. Currently, only phoenix-client-4.14.1-hbase-1.4 is supported by
> prestosql, because I only found
> phoenix-client-4.14.1-hbase-1.4-embedded.jar in / presto-server-322 /
> plugin / Phoenix. So Presto still can't support
> apache-phoenix-5.0.0-hbase-2.0？
> Thinks，My Friend。

Re: [VOTE] Accept Tephra and Omid podlings as Phoenix sub-projects

[Vincent Poon]

+1

On Wed, Oct 30, 2019 at 8:57 AM William Shen 
wrote:

> +1!
>
> On Wed, Oct 30, 2019 at 8:27 AM Josh Elser  wrote:
>
> > Hi,
> >
> > As was previously discussed[1][2], there is a motion to "adopt" the
> > Tephra and Omid podlings as sub-projects to Apache Phoenix. A
> > sub-project is a distinct software project from some top-level project
> > (TLP) but operates under the guidance of a TLP (e.g. the TLP's PMC)
> >
> > Per the Incubator guidelines[3], we need to have a formal vote to adopt
> > them. While we still need details from these two podlings, I believe we
> > can have a VOTE now to keep things moving.
> >
> > Actions:
> > * Phoenix will incorporate Omid and Tephra as sub-projects and they will
> > continue to function under the Apache Phoenix PMC guidance.
> > * Any current podling member may request to be added as a Phoenix
> > committer. Podling members would be expected to demonstrate the normal
> > level of commitment to grow from a committer to a PMC member.
> >
> > Stating what I see as an implicit decision (but to alleviate any
> > possible confusion): all new community members will be expected to
> > function in the way that Phoenix currently does today (e.g
> > review-then-commit). Future Omid and Tephra development would happen in
> > the same way that Phoenix development happens today.
> >
> > Please vote:
> >
> > +1: to accept Omid and Tephra as Phoenix sub-projects and to allow any
> > PPMC to become Phoenix committers.
> >
> > -1/-0/+0: No and why..
> >
> > Here is my +1 (binding)
> >
> > This vote will be open for at least 72hrs (2019/11/02 1600 UTC).
> >
> >
> > [1]
> >
> >
> https://lists.apache.org/thread.html/ec00615cbbb4225885e3776f1e8fd071600a9c50f35769f453b8a779@%3Cdev.phoenix.apache.org%3E
> > [2]
> >
> >
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> > [3]
> >
> >
> https://incubator.apache.org/guides/graduation.html#graduating_to_a_subproject
> >
>

Re: [DISCUSS] Omid and Tephra podlings

[Vincent Poon]

+1
I don't think pulling these under Phoenix would change their volume of
activity in the near term.
However, when/if usage of transactions with Phoenix increases, we'd want a
path forward to be able to make modifications where necessary to these
projects.
This seems the best way to ensure there's an expedient way to do that.

On Fri, Oct 25, 2019 at 10:36 AM James Taylor 
wrote:

> +1 to pulling these projects into Phoenix. We’ve already done some work in
> those projects and so have some familiarity with them. We also have some
> overlap in the committers with Omid. At a minimum we’d need to create new
> compat modules when necessary for future HBase releases. The alternative
> would be to rip out the transaction support which would be a mistake IMHO.
>
> On Fri, Oct 25, 2019 at 8:08 AM Josh Elser  wrote:
>
> > I share your same hesitation. I'm worried about us adopting code that no
> > one intends to actually maintain.
> >
> > My immediate concern is whether adoption of these codebases would impact
> > the PMC's ability to develop on Phoenix -- I think there's a path
> > forward to avoid that. Is that sufficient to say we "should" adopt them?
> > I dunno.
> >
> > On 10/24/19 5:37 PM, Andrew Purtell wrote:
> > > Tephra and Omid are interesting in that they serve a similar function
> - a
> > > transaction oracle - but scale differently per different choices in
> > design,
> > > so one is more appropriate for some kinds of transactional workloads vs
> > the
> > > other. It's akin to secondary indexing, there is not an index type that
> > > fits all use cases. If you are going to consider one, you should
> consider
> > > both. That said my guess is you will find eventually one is the
> 'winner'
> > > per second order measures like contributions or user issues. This
> should
> > be
> > > fine. As separate repositories they can move at their own speed and
> only
> > > consume bandwidth as usage and uptake actually demands.
> > >
> > > For what it's worth I'd vote as PMC +0 on accepting these code bases.
> '+'
> > > because Phoenix transactional indexes are a promising feature, and
> could
> > be
> > > compelling, and they need one of these transaction oracles. '0' because
> > it
> > > would be unfair to commit someone else's time. I'm not around here
> > much...
> > > but may be around more going forward.
> > >
> > > On Thu, Oct 24, 2019 at 10:14 AM Josh Elser  wrote:
> > >
> > >> Hiya folks,
> > >>
> > >> There's a discussion[1] on general@incubator about the Omid and
> Tephra
> > >> podlings, their decrease in volume (commits, discussion, activity),
> and
> > >> what to do about them. If you'd like to contribute to that discussion,
> > >> please watch on general@incubator and the dev lists for those
> podlings.
> > >>
> > >> One idea that seems to have resonated was that the Phoenix PMC could
> > >> "adopt" the codebases for Omid and Tephra.
> > >>
> > >> While this is by no means a "done decision", but I thought it would be
> > >> good for us to think about this, decide if it's something we think we
> > >> want to entertain, and how would would technically do this.
> > >>
> > >> As far as a PMC goes, we are allowed to have multiple projects under
> one
> > >> PMC. We could move the tephra and omid repositories under the control
> of
> > >> our PMC, and manage them just like we do phoenix, phoenix-connectors,
> > >> phoenix-queryserver, etc.
> > >>
> > >> Thankfully, with the work of the transaction abstraction layer, we
> > >> shouldn't be in any position where Phoenix development would get
> "stuck"
> > >> by work that needed to be done in Omid or Tephra.
> > >>
> > >> What do folks think? Is this a good idea? Do we have enough interest
> to
> > >> keep the codebases healthy?
> > >>
> > >> - Josh
> > >>
> > >> [1]
> > >>
> > >>
> >
> https://lists.apache.org/thread.html/692a030a27067c20b9228602af502199cd4d80eb0aa8ed6461ebe1ee@%3Cgeneral.incubator.apache.org%3E
> > >>
> > >
> > >
> >
>

Re: [VOTE] Release of Apache Phoenix 4.15.0 RC0

[Vincent Poon]

Yea, I should have mentioned:
This was built from source on the 1.3 branch, using the hash Chinmay
provided: d41cc
This was before any 4.15 client connected (i.e. metadata was not upgraded)
So, this is a backwards compatibility issue.

On Fri, Oct 18, 2019 at 4:25 PM la...@apache.org  wrote:

>  Did you use one of the provided tarballs (in that case, which one)? Or
> build from source (in that case, which branch?).
> Also was that before or after the first 4.15 client connected with the
> cluster (i.e. was the meta data upgraded or not)?
> That would be a blocker, indeed. :(
> -- Lars
> On Friday, October 18, 2019, 04:09:11 PM PDT, Vincent Poon <
> vincentp...@apache.org> wrote:
>
>  I'm also not able to create an index with the older client:
>
> 2019-10-18 16:06:26,569 ERROR
> [RpcServer.FifoWFPBQ.default.handler=255,queue=21,port=16201]
> coprocessor.MetaDataEndpointImpl: createTable failed
> java.lang.NullPointerException
> at
>
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.createTable(MetaDataEndpointImpl.java:1758)
> at
>
> org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:17218)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:8270)
> at
>
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:2207)
> at
>
> org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:2189)
> at
>
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35076)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2373)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)
>
> On Fri, Oct 18, 2019 at 3:21 PM Vincent Poon 
> wrote:
>
> > -1
> > I still see PHOENIX-5103 still cropping up for "DROP TABLE" when using
> the
> > 4.14 client against 4.15 server.  However, it seems "CREATE TABLE" works
> > fine.
> >
> > Caused by: org.apache.hadoop.hbase.TableNotFoundException:
> > org.apache.hadoop.hbase.TableNotFoundException: Table 'SYSTEM:CHILD_LINK'
> > was not found, got: SYSTEM:CATALOG.
> > at
> >
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1323)
> > at
> >
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1195)
> > at
> >
> org.apache.hadoop.hbase.client.CoprocessorHConnection.locateRegion(CoprocessorHConnection.java:41)
> > at
> >
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:303)
> > at
> >
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:156)
> > at
> >
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
> > at
> >
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:212)
> > at
> > org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:314)
> > at
> >
> org.apache.hadoop.hbase.client.ClientScanner.nextScanner(ClientScanner.java:289)
> > at
> >
> org.apache.hadoop.hbase.client.ClientScanner.initializeScannerInConstruction(ClientScanner.java:164)
> > at
> >
> org.apache.hadoop.hbase.client.ClientScanner.(ClientScanner.java:159)
> > at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:803)
> > at
> >
> org.apache.hadoop.hbase.client.HTableWrapper.getScanner(HTableWrapper.java:235)
> > at org.apache.phoenix.util.ViewUtil.hasChildViews(ViewUtil.java:163)
> > at
> >
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.doDropTable(MetaDataEndpointImpl.java:2303)
> > at
> >
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:2153)
> >
> >
> > On Fri, Oct 18, 2019 at 2:36 PM Chinmay Kulkarni <
> > chinmayskulka...@gmail.com> wrote:
> >
> >> *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC0*
> >>
> >> Just sending out a friendly reminder to everyone to please vote on
> Apache
> >> Phoenix 4.15.0 RC0 (thanks Lars).
> >>
> >> On Thu, Oct 17, 2019 at 3:28 PM la...@apache.org 
> >> wrote:
> >>
> >> >  +1 (binding)
> >> > - Built from source
> >> > - Went through

Re: [VOTE] Release of Apache Phoenix 4.15.0 RC0

[Vincent Poon]

I'm also not able to create an index with the older client:

2019-10-18 16:06:26,569 ERROR
[RpcServer.FifoWFPBQ.default.handler=255,queue=21,port=16201]
coprocessor.MetaDataEndpointImpl: createTable failed
java.lang.NullPointerException
at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.createTable(MetaDataEndpointImpl.java:1758)
at
org.apache.phoenix.coprocessor.generated.MetaDataProtos$MetaDataService.callMethod(MetaDataProtos.java:17218)
at
org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:8270)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:2207)
at
org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:2189)
at
org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35076)
at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2373)
at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:124)
at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:188)
at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)

On Fri, Oct 18, 2019 at 3:21 PM Vincent Poon  wrote:

> -1
> I still see PHOENIX-5103 still cropping up for "DROP TABLE" when using the
> 4.14 client against 4.15 server.  However, it seems "CREATE TABLE" works
> fine.
>
> Caused by: org.apache.hadoop.hbase.TableNotFoundException:
> org.apache.hadoop.hbase.TableNotFoundException: Table 'SYSTEM:CHILD_LINK'
> was not found, got: SYSTEM:CATALOG.
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1323)
> at
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1195)
> at
> org.apache.hadoop.hbase.client.CoprocessorHConnection.locateRegion(CoprocessorHConnection.java:41)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:303)
> at
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:156)
> at
> org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
> at
> org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:212)
> at
> org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:314)
> at
> org.apache.hadoop.hbase.client.ClientScanner.nextScanner(ClientScanner.java:289)
> at
> org.apache.hadoop.hbase.client.ClientScanner.initializeScannerInConstruction(ClientScanner.java:164)
> at
> org.apache.hadoop.hbase.client.ClientScanner.(ClientScanner.java:159)
> at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:803)
> at
> org.apache.hadoop.hbase.client.HTableWrapper.getScanner(HTableWrapper.java:235)
> at org.apache.phoenix.util.ViewUtil.hasChildViews(ViewUtil.java:163)
> at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.doDropTable(MetaDataEndpointImpl.java:2303)
> at
> org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:2153)
>
>
> On Fri, Oct 18, 2019 at 2:36 PM Chinmay Kulkarni <
> chinmayskulka...@gmail.com> wrote:
>
>> *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC0*
>>
>> Just sending out a friendly reminder to everyone to please vote on Apache
>> Phoenix 4.15.0 RC0 (thanks Lars).
>>
>> On Thu, Oct 17, 2019 at 3:28 PM la...@apache.org 
>> wrote:
>>
>> >  +1 (binding)
>> > - Built from source
>> > - Went through a simple 4.14 to 4.15 upgrade- Loaded a few dozens of
>> > millions of rows.- Tried global and local indexes.- Tried HBase 1.5.0-
>> > Nothing weird in the logs.
>> > Looks good.
>> > On a related note: I'd really love us to go back to a monthly release
>> > train. That would lead to smaller and more stable releases.Let's
>> schedule
>> > 4.15.1 (and perhaps 5.1.1...?) in a month from now. (If Chinmay is
>> tired of
>> > it, I'll volunteer to be RM :))
>> >
>> > -- Lars
>> >
>> > On Thursday, October 17, 2019, 3:05:32 PM PDT, Chinmay Kulkarni <
>> > chinmayskulka...@gmail.com> wrote:
>> >
>> >  Hello Everyone,
>> >
>> > This is a call for a vote on Apache Phoenix 4.15.0 RC0. This is the next
>> > minor release of Phoenix 4, compatible with Apache HBase 1.3, 1.4, &
>> > 1.5. The release includes both a source-only release and a convenience
>> > binary release for each supported HBase version.
>> >
>> > This release has feature parity with supported HBase versions and
>> includes
>> >

Re: [VOTE] Release of Apache Phoenix 4.15.0 RC0

[Vincent Poon]

-1
I still see PHOENIX-5103 still cropping up for "DROP TABLE" when using the
4.14 client against 4.15 server.  However, it seems "CREATE TABLE" works
fine.

Caused by: org.apache.hadoop.hbase.TableNotFoundException:
org.apache.hadoop.hbase.TableNotFoundException: Table 'SYSTEM:CHILD_LINK'
was not found, got: SYSTEM:CATALOG.
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1323)
at
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1195)
at
org.apache.hadoop.hbase.client.CoprocessorHConnection.locateRegion(CoprocessorHConnection.java:41)
at
org.apache.hadoop.hbase.client.RpcRetryingCallerWithReadReplicas.getRegionLocations(RpcRetryingCallerWithReadReplicas.java:303)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:156)
at
org.apache.hadoop.hbase.client.ScannerCallableWithReplicas.call(ScannerCallableWithReplicas.java:60)
at
org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:212)
at org.apache.hadoop.hbase.client.ClientScanner.call(ClientScanner.java:314)
at
org.apache.hadoop.hbase.client.ClientScanner.nextScanner(ClientScanner.java:289)
at
org.apache.hadoop.hbase.client.ClientScanner.initializeScannerInConstruction(ClientScanner.java:164)
at
org.apache.hadoop.hbase.client.ClientScanner.(ClientScanner.java:159)
at org.apache.hadoop.hbase.client.HTable.getScanner(HTable.java:803)
at
org.apache.hadoop.hbase.client.HTableWrapper.getScanner(HTableWrapper.java:235)
at org.apache.phoenix.util.ViewUtil.hasChildViews(ViewUtil.java:163)
at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.doDropTable(MetaDataEndpointImpl.java:2303)
at
org.apache.phoenix.coprocessor.MetaDataEndpointImpl.dropTable(MetaDataEndpointImpl.java:2153)


On Fri, Oct 18, 2019 at 2:36 PM Chinmay Kulkarni 
wrote:

> *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC0*
>
> Just sending out a friendly reminder to everyone to please vote on Apache
> Phoenix 4.15.0 RC0 (thanks Lars).
>
> On Thu, Oct 17, 2019 at 3:28 PM la...@apache.org  wrote:
>
> >  +1 (binding)
> > - Built from source
> > - Went through a simple 4.14 to 4.15 upgrade- Loaded a few dozens of
> > millions of rows.- Tried global and local indexes.- Tried HBase 1.5.0-
> > Nothing weird in the logs.
> > Looks good.
> > On a related note: I'd really love us to go back to a monthly release
> > train. That would lead to smaller and more stable releases.Let's schedule
> > 4.15.1 (and perhaps 5.1.1...?) in a month from now. (If Chinmay is tired
> of
> > it, I'll volunteer to be RM :))
> >
> > -- Lars
> >
> > On Thursday, October 17, 2019, 3:05:32 PM PDT, Chinmay Kulkarni <
> > chinmayskulka...@gmail.com> wrote:
> >
> >  Hello Everyone,
> >
> > This is a call for a vote on Apache Phoenix 4.15.0 RC0. This is the next
> > minor release of Phoenix 4, compatible with Apache HBase 1.3, 1.4, &
> > 1.5. The release includes both a source-only release and a convenience
> > binary release for each supported HBase version.
> >
> > This release has feature parity with supported HBase versions and
> includes
> > the following improvements:
> > - Support for multi-region SYSTEM.CATALOG
> > - Omid integration with Phoenix
> > - Orphan view tool
> > - Separation of the Phoenix-Connectors and Phoenix-Queryserver projects
> > - 150+ bug fixes
> > and much more
> >
> > The source tarball, including signatures, digests, etc can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.3-rc0/src/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.4-rc0/src/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.5-rc0/src/
> >
> > The binary artifacts can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.3-rc0/bin/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.4-rc0/bin/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.15.0-HBase-1.5-rc0/bin/
> >
> > For a complete list of changes, see:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12343162
> >
> > Artifacts are signed with my "CODE SIGNING KEY":
> > 7C5FC713DE4C59D7
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> >
> > The hash and tag to be voted upon:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=d41cc51d0b593bba4bc70b6edc95afb807fe8899
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.15.0-HBase-1.3-rc0
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=403607fa969d9cc760572f065e0b41027c8d584c
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v4.15.0-HBase-1.4-rc0
> >
> >
> >
> 

[jira] [Created] (PHOENIX-5528) Race condition in index verification causes multiple index rows to be returned for single data table row

[Vincent Poon (Jira)]

Vincent Poon created PHOENIX-5528:
-

 Summary: Race condition in index verification causes multiple 
index rows to be returned for single data table row
 Key: PHOENIX-5528
 URL: https://issues.apache.org/jira/browse/PHOENIX-5528
 Project: Phoenix
  Issue Type: Bug
Reporter: Vincent Poon


Warning: This is an artificially generated scenario that likely has a very low 
probability of happening in practice.  But a race condition nevertheless.  
Unfortunately I don't have a test case, but was able to produce this by 
debugging a local regionserver and adding breakpoints at the right places to 
produce the ordering here.

The core problem is that when we do an update to the data table, we produce two 
unverified index rows at first.  When we scan both of these index rows and 
attempt to verify via rebuilding the data table row, we cannot guarantee that 
both verifications happen before the data table update, or both happen after 
the data table update.

I use multiple index regions here to demonstrate, but I believe it could happen 
within a single region as well.

Steps:
1) Create a test table with "pk" and "indexed_val" columns, and a global index 
on "indexed_val".
2) upsert into test values ('test_pk', 'test_val');
3) Split the index table on 'test_pk':
   hbase shell: split 'test_index', 'test_pk'.
   This creates two regions, call them regionA and regionB (which holds the 
existing index row)
3) start an update: upsert into test values ('test_pk', 'new_val');
   The first thing the indexing code does is create two unverified index rows: 
one is a new version of the existing index row, and the other is for the new 
indexed value.
   We pause the thread after this is done, before the row locks and data table 
write happens.
4) select indexed_val from test;
   This scans both the index regions in parallel.  Each scan picks up a 
unverified row in its region.  We pause in GlobalIndexChecker.
   Let the regionB scan proceed.  It will attempt to rebuild the data table 
row.  The data table still has 'test_val' as the indexed value.  The rebuild 
succeeds.
   scan on regionA still paused.
5) The original update proceeds to update the data table indexed value to 
'new_val'.
6) The scan on regionA proceeds, and attempted to rebuild the data table row.  
The rebuild succeeds with 'new_val' as the indexed value.
7) Both 'test_val' and 'new_val' are returned to the client, because both 
rebuilds succeeded.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Reopened] (PHOENIX-5515) Able to write indexed value to data table without writing to index table

[Vincent Poon (Jira)]

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

Vincent Poon reopened PHOENIX-5515:
---

> Able to write indexed value to data table without writing to index table
> 
>
> Key: PHOENIX-5515
> URL: https://issues.apache.org/jira/browse/PHOENIX-5515
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.3
>    Reporter: Vincent Poon
>Assignee: Kadir OZDEMIR
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5515.master.001.patch, 
> PHOENIX-5515.master.002.patch
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Using the 4.14.3 client, it still seems the IndexFailurePolicy is still 
> kicking in, which disables the index on write failure.  This means that while 
> the index is in 'disabled' state, writes to the data table can happen without 
> any writes to the index table.  While in theory this might be ok since the 
> rebuilder should eventually kick in and rebuild from the disable_timestamp, 
> this breaks the new indexing design invariant that there should be no data 
> table rows without a corresponding index row (potentially unverified), so 
> this could potentially cause some unexpected behavior.
> Steps to repro:
> 1) Create data table
> 2) Create index table
> 3) "close_region" on index region from hbase shell
> 4) Upsert to data table
> Eventually after some number of retries, the index will get disabled, which 
> means any other client can write to the data table without writing to the 
> index table.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (PHOENIX-5515) Able to write indexed value to data table without writing to index table

[Vincent Poon (Jira)]

Vincent Poon created PHOENIX-5515:
-

 Summary: Able to write indexed value to data table without writing 
to index table
 Key: PHOENIX-5515
 URL: https://issues.apache.org/jira/browse/PHOENIX-5515
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.14.3
Reporter: Vincent Poon


Using the 4.14.3 client, it still seems the IndexFailurePolicy is still kicking 
in, which disables the index on write failure.  This means that while the index 
is in 'disabled' state, writes to the data table can happen without any writes 
to the index table.  While in theory this might be ok since the rebuilder 
should eventually kick in and rebuild from the disable_timestamp, this breaks 
the new indexing design invariant that there should be no data table rows 
without a corresponding index row (potentially unverified), so this could 
potentially cause some unexpected behavior.

Steps to repro:
1) Create data table
2) Create index table
3) "close_region" on index region from hbase shell
4) Upsert to data table
Eventually after some number of retries, the index will get disabled, which 
means any other client can write to the data table without writing to the index 
table.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Assigned] (PHOENIX-5430) Update Generate a patch session on contributing page

[Vincent Poon (Jira)]

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

Vincent Poon reassigned PHOENIX-5430:
-

Assignee: Christine Feng

> Update Generate a patch session on contributing page
> 
>
> Key: PHOENIX-5430
> URL: https://issues.apache.org/jira/browse/PHOENIX-5430
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Xinyi Yan
>Assignee: Christine Feng
>Priority: Trivial
> Attachments: PHOENIX-5430.patch
>
>
> Our Contributing page is out of date, and I saw new contributors try to work 
> on 4.x-HBase-1.2 branch. For this reason, we need to remove `4.x-HBase-1.2` 
> and add `4.x-HBase-1.5` info at Generate a patch session.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (PHOENIX-5456) IndexScrutinyTool slow for indexes on multitenant tables

[Vincent Poon (Jira)]

Vincent Poon created PHOENIX-5456:
-

 Summary: IndexScrutinyTool slow for indexes on multitenant tables
 Key: PHOENIX-5456
 URL: https://issues.apache.org/jira/browse/PHOENIX-5456
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.15.0, 5.1.0
Reporter: Vincent Poon


The IndexScrutinyTool is doing full scans for index tables on multitenant 
tables. 
This is due to a change in PHOENIX-5089, where we added code to 
IndexColumnNames to skip a portion of the PK if the table is multitenant:

https://github.com/apache/phoenix/commit/cc9754fff840f38d13c3adb0c963296959fff3fa#diff-0705645faa779229d00792c032ed377fR64

This causes scrutinies for global, non-view indexes on multitenant tables to 
skip the tenantId when generating the pk column list, thereby causing a full 
scan.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

Re: [ANNOUNCE] New Phoenix PMC Member: Chinmay Kulkarni

[Vincent Poon]

Congrats, Chinmay!

On Mon, Aug 26, 2019 at 10:34 AM Geoffrey Jacoby  wrote:

> Each Apache project is governed by a Project Management Committee, or PMC.
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Chinmay
> Kulkarni has accepted our invitation to join. Chinmay has been a dedicated
> contributor and committer, and has recently volunteered to be RM for our
> upcoming major 4.15 and 5.1 releases.
>
> Please join me in welcoming Chinmay!
>
> Geoffrey Jacoby
>

Re: [VOTE] Release of Apache Phoenix 4.14.3 RC2

[Vincent Poon]

+1
Ran the core tests which passed, except for SaltedIndexIT (it seems that is
failing consistently for people when run as part of full suite?).
In any case, not a blocker.

On Fri, Aug 16, 2019 at 1:39 PM Geoffrey Jacoby  wrote:

> Vote: +1
>
> rat-check: OK
> Signature-check: OK
> Checksums: OK
> mvn clean verify: OK after hand-verifying some flappers.
>
> In addition to SaltedIndexIT, also saw some flappers on NativeHBaseTypesIT
> and ViewIT. Also HiveMapReduceIT has a habit of hanging on one machine I
> tested on. Since I don't expect many more, if any, 4.14 releases after
> this, and a lot of test stability work has gone into 4.15, I don't see a
> need to hold up this release on a flapper-killing quest.
>
> Sqlline test of table creation, population, index building, and verifying
> that indexes stay in sync after CRUD operations: OK
>
> Geoffrey
>
>
> On Fri, Aug 16, 2019 at 9:55 AM Chinmay Kulkarni <
> chinmayskulka...@gmail.com>
> wrote:
>
> > Vote: +1
> >
> > - apache-rat check: PASS
> > - Signatures and checksums: PASS
> > - mvn clean install -DskipTests: PASS
> > - Built from source and used sqlline to do basic DDL table/index
> creations.
> > Upserted a bunch of rows and tried some basic queries: PASS
> > - mvn package: (All UTs and ITs were green, except SaltedIndexIT which
> is a
> > known flapper) PASS
> >
> > Thanks,
> > Chinmay
> >
> > On Thu, Aug 15, 2019 at 2:34 PM Artem Ervits 
> > wrote:
> >
> > > vote: 4.14.3rc2-HBase-1.4
> > > +1 (non-binding)
> > >
> > > Sql: OK
> > > inserted rows with Java: OK
> > > ran code with Spark 2.3.3: OK
> > > signatures and sums for src and bin: OK
> > > installed binary on pseudodistributed hadoop 2.8.5 with hbase 1.4.10:
> OK
> > > mvn package: OK
> > >
> > > On Wed, Aug 14, 2019 at 1:24 PM swaroopa kadam <
> > swaroopa.kada...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello Everyone,
> > > >
> > > > This is a call for a vote on Apache Phoenix 4.14.3 RC2. This is a
> patch
> > > > release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
> > > > 1.4. The release includes both a source-only release and a
> convenience
> > > > binary
> > > > release for each supported HBase version.
> > > >
> > > > This release includes critical bug fixes and improvements for
> secondary
> > > > indexes -- making them self-consistent.
> > > >
> > > > The source tarball, including signatures, digests, etc can be found
> at:
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc2/src/
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc2/src/
> > > >
> > > > The binary artifacts can be found at:
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc2/bin/
> > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc2/bin/
> > > >
> > > > For a complete list of changes, see:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12345601
> > > >
> > > > Artifacts are signed with my "CODE SIGNING KEY": 48B7807D95F127B5
> > > >
> > > > KEYS file available here:
> > > > https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> > > >
> > > > The tag to be voted upon:
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=e2993552dc88cb7fc59fc0dfdaa2876ac260886c
> > > >
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=eb5424573bd2f5f247a61d1a28da81fb92f06ec6
> > > >
> > > > The vote will be open for at least 72 hours. Please vote:
> > > >
> > > > [ ] +1 approve
> > > > [ ] +0 no opinion
> > > > [ ] -1 disapprove (and the reason why)
> > > >
> > > > Thanks,
> > > > The Apache Phoenix Team
> > > >
> > > > --
> > > >
> > > >
> > > > Swaroopa Kadam
> > > > [image: https://]about.me/swaroopa_kadam
> > > > <
> > > >
> > >
> >
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> > > > >
> > > >
> > >
> >
> >
> > --
> > Chinmay Kulkarni
> >
>

Re: Phoenix Connector on Secure Cluster

[Vincent Poon]

Try using an hbase-site.xml (on both HBase server and presto-phoenix
client) with the following properties: hbase.security.authentication (set
to ‘kerberos’), hadoop.security.authentication (set to ‘kerberos’),
hbase.regionserver.kerberos.principal, hbase.regionserver.keytab.file,
hbase.master.kerberos.principal,hbase.master.keytab.file.  You also need to
make sure krb5.conf is in the right place for your OS, or else start the
Presto jvm with -Djava.security.krb5.conf=

On Thu, Aug 15, 2019 at 7:31 AM Vasileios Dimakopoulos <
vasileios.dimakopou...@cern.ch> wrote:

> Dear Phoenix Development Team,
>
> I am Big Data Engineer at CERN and we deployed presto as part of our tests
> to create an abstract SQL layer on top of our data sources and backends
> (HDFS, HBase, Relational Databases, Kafka, etc). In order to query HBase we
> have also deployed successfully Phoenix and the missing puzzle piece  to
> the abstraction is integrating Phoenix with Presto. However we face some
> issues which mainly stem from Kerberos authentication, impersonation and in
> general with the delegation of the token. Therefore I would like to ask you
> if the Phoenix connector could support a secure HBase cluster and if this
> is the case could you guide us or give us any insight on achieving that?
>
> Thank you in advance.
>
> Vasileios Dimakopoulos
>
> CERN Big Data Engineer / Electrical & Computer Engineer
>
> -
> Secondary email: vdimakopou...@isc.tuc.gr
> LinkedIn
>

Re: [VOTE] Release of Apache Phoenix 4.14.3 RC1

[Vincent Poon]

I saw the the same flapping with SaltedIndexIT

On Mon, Aug 12, 2019 at 4:48 PM Geoffrey Jacoby  wrote:

> Vote: -1, for the same reason as Artem above.
>
> (I also agree with Artem that the Maven problems he identified aren't
> blockers for this release, though we need to fix them for the future. Maybe
> make them blockers for 4.15 to make sure we remember? Chinmay, wdyt?)
>
> Rat-check: OK
> Keys: OK
> mvn clean verify: FAILED
> [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.034 s <<< FAILURE! - in org.apache.phoenix.pherf.ConfigurationParserTest
> [ERROR] testConfigReader(org.apache.phoenix.pherf.ConfigurationParserTest)
>  Time elapsed: 0.015 s  <<< FAILURE!
> java.lang.AssertionError
> at
>
> org.apache.phoenix.pherf.ConfigurationParserTest.testConfigReader(ConfigurationParserTest.java:121)
>
> There was also a failure in SaltedIndexIT, but it appears to be a flapper
> because it passed when run standalone.
>
> Running the ConfigurationParserTest in my IDE, I get the following stack
> trace. Looks like another case where a scenario name isn't being set:
> java.lang.NullPointerException
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:191)
> at
> org.apache.phoenix.pherf.configuration.Scenario.getName(Scenario.java:168)
> [lots of JAXB internals]
> at
>
> org.apache.phoenix.pherf.ConfigurationParserTest.writeXML(ConfigurationParserTest.java:239)
> at
>
> org.apache.phoenix.pherf.ConfigurationParserTest.testConfigReader(ConfigurationParserTest.java:68)
>
> Geoffrey
>
> On Mon, Aug 12, 2019 at 2:29 PM Artem Ervits 
> wrote:
>
> > vote: 4.14.3RC1-HBase-1.4
> > -1 (non-binding)
> >
> > sqlline-thin various commands: OK
> > inserted rows with Java: OK
> > ran code with Spark 2.3.3: OK
> > signatures and sums for src and bin: OK though Swaroopa's keys are in dev
> > KEYS and not in release, same issue as past votes. The announcement does
> > point to the right KEYS however.
> > installed binary on pseudodistributed hadoop 2.8.5 with hbase 1.4.10: OK
> > mvn install -DskipTests 1.8.0_222-b10: OK
> > mvn package: NOK
> >
> > filed: https://issues.apache.org/jira/browse/PHOENIX-5439
> > https://issues.apache.org/jira/browse/PHOENIX-5440
> >
> > but I didn't think those were blockers until I tried running mvn package
> > w/out any flags
> >
> > [ERROR] Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> > 0.074 s <<< FAILURE! - in
> org.apache.phoenix.pherf.ConfigurationParserTest
> > [ERROR]
> testConfigReader(org.apache.phoenix.pherf.ConfigurationParserTest)
> >  Time elapsed: 0.022 s  <<< FAILURE!
> > java.lang.AssertionError
> > at
> >
> >
> org.apache.phoenix.pherf.ConfigurationParserTest.testConfigReader(ConfigurationParserTest.java:121)
> >
> > [INFO] Running org.apache.phoenix.pherf.ResultTest
> > [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > 4.415 s - in org.apache.phoenix.pherf.ResultTest
> > [INFO] Running org.apache.phoenix.pherf.result.impl.XMLResultHandlerTest
> > [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> > 0.037 s - in org.apache.phoenix.pherf.result.impl.XMLResultHandlerTest
> > [INFO]
> > [INFO] Results:
> > [INFO]
> > [ERROR] Failures:
> > [ERROR]   ConfigurationParserTest.testConfigReader:121
> > [INFO]
> > [ERROR] Tests run: 31, Failures: 1, Errors: 0, Skipped: 0
> > [INFO]
> > [INFO]
> > 
> > [INFO] Reactor Summary for Apache Phoenix 4.14.3-HBase-1.4:
> > [INFO]
> > [INFO] Apache Phoenix . SUCCESS [
> >  2.070 s]
> > [INFO] Phoenix Core ... SUCCESS
> [02:53
> > min]
> > [INFO] Phoenix - Flume  SUCCESS [
> >  3.357 s]
> > [INFO] Phoenix - Kafka  SUCCESS [
> >  2.396 s]
> > [INFO] Phoenix - Pig .. SUCCESS
> [01:03
> > min]
> > [INFO] Phoenix Query Server Client  SUCCESS [
> > 13.323 s]
> > [INFO] Phoenix Query Server ... SUCCESS [
> > 13.345 s]
> > [INFO] Phoenix - Pherf  FAILURE [
> > 12.053 s]
> > [INFO] Phoenix - Spark  SKIPPED
> > [INFO] Phoenix - Hive . SKIPPED
> > [INFO] Phoenix Client . SKIPPED
> > [INFO] Phoenix Server . SKIPPED
> > [INFO] Phoenix Assembly ... SKIPPED
> > [INFO] Phoenix - Tracing Web Application .. SKIPPED
> > [INFO] Phoenix Load Balancer .. SKIPPED
> >
> >
> > also see issue with opening archives
> >
> >
> apache-phoenix-4.14.3-HBase-1.4-src/src/main/config/checkstyle/checker.xml
> > tar: Ignoring unknown extended header keyword `SCHILY.dev'
> > tar: Ignoring unknown extended header keyword 

Re: [DISCUSS] Board report due 2019/08/14

[Vincent Poon]

4.14.2 released, 4.14.3 nearing completion
PHOENIX-5156 for consistent global indexes is a big improvement
New integrations with Presto and Spark

On Tue, Aug 13, 2019 at 9:36 AM William Shen 
wrote:

> A couple things that might be noteworthy:
> - Thanks to Lars, we now have a fully passing integration test:
> https://builds.apache.org/job/Phoenix-4.x-HBase-1.5/ (since June IIRC)
> - Interesting discussion titled "is Apache phoenix reliable enough?" on the
> user list, where people shared their experience of using Phoenix.
>
> On Tue, Aug 13, 2019 at 8:18 AM Josh Elser  wrote:
>
> > *bump*
> >
> > Shaping up to be a really thin board report.
> >
> > On 2019/08/06 18:00:19, Josh Elser  wrote: > Hiya
> > folks,
> > >
> > > It's time again for our quarterly report to the ASF board.
> > >
> > > It's immensely helpful for you all to give me what _you_ see as the
> > > highlights of the project. What happened in the past three months that
> > > give someone on the sidelines insight into our little corner of the
> FOSS
> > > world? Anything from simple to detailed is helpful.
> > >
> > > Thanks in advance.
> > >
> > > - Josh
> > >
> >
>

Re: [DISCUSS] Maintaining the Site in Git Instead of SVN

[Vincent Poon]

I think the confusion here is stemming from two different things:
1)  Moving docs from SVN to git (potentially its own repo)
2) Moving docs into the same apache/phoenix repo as the source code.

I think we should do #1, and not #2, which avoids the concerns Thomas and
James have.

On Mon, Jun 3, 2019 at 10:46 AM James Taylor  wrote:

> The problem with committing docs with code is that the release happens much
> later. We’ve always tried to get the doc changes pushed out before the
> release is cut.
>
> On Mon, Jun 3, 2019 at 9:30 AM William Shen 
> wrote:
>
> > Thomas, that makes sense now. thanks for explaining. didnt catch that the
> > first time. would it make sense to you guys that we publish the website
> > from master, or should we publish from say the latest of 4.x?
> >
> > On Mon, Jun 3, 2019 at 9:11 AM Thomas D'Silva
> >  wrote:
> >
> > > William, I was referring to your comment about ensuring doc changes are
> > > checked in with code changes.
> > > I assume you meant this meant that the doc change would go in to the
> same
> > > pull request as the code change?
> > > But I guess since we currently mostly commit patches to all branches
> this
> > > should be fine. We could have the website
> > > module in one of the branches.
> > >
> > > On Sun, Jun 2, 2019 at 10:53 PM William Shen <
> wills...@marinsoftware.com
> > >
> > > wrote:
> > >
> > > > I think we do need to come up with a strategy on how to maintain
> > website
> > > > documentation given that we have several versions that may
> potentially
> > > > conflict in documentation at times. Thomas, is this your main
> concern?
> > > >
> > > >
> > > > Josh - Would love to help drive it, though I’m not sure if i have all
> > the
> > > > right access to do so.
> > > > Seems like we would need to:
> > > > - commit the svn site directory into git master (I can create a patch
> > but
> > > > would need help committing this)
> > > > - file an infra ticket to migrate the website, and enable git-pubsub
> > > > (though I’m totally speak out of my knowledge here...)
> > > >
> > > > On Sun, Jun 2, 2019 at 11:42 AM Josh Elser 
> > wrote:
> > > >
> > > > > Yeah, not sure I get your concern, Thomas. We only have one
> website.
> > > > >
> > > > > From the ASF Infra side, svn-pubsub (what deploys our code on SVN
> > > > > check-in) works the same as git-pubsub. It should just be a request
> > to
> > > > > Infra to migrate the website from SVN to Git and then enable
> > > > > git-pubsub.
> > > > >
> > > > > No concerns in doing this from me. Even better if you'd like to
> drive
> > > > > it, William ;)
> > > > >
> > > > > On Fri, May 31, 2019 at 2:24 PM William Shen <
> > > wills...@marinsoftware.com
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Thomas,
> > > > > >
> > > > > > Which release line do we currently base our documentation on? Do
> > you
> > > > > think
> > > > > > it makes sense to bring the site source into master, and always
> > > update
> > > > > the
> > > > > > site from master?
> > > > > >
> > > > > > - Will
> > > > > >
> > > > > > On Thu, May 30, 2019 at 8:46 PM Thomas D'Silva
> > > > > >  wrote:
> > > > > >
> > > > > > > Currently this would not be easy to do since we have multiple
> > > > > branches. If
> > > > > > > we decide to
> > > > > > > implement Lars' proposal to have a single branch and a module
> per
> > > > > supported
> > > > > > > HBase version
> > > > > > > then we could have a module for the website as well.
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 7:03 PM swaroopa kadam <
> > > > > swaroopa.kada...@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Huge +1!
> > > > > > > >
> > > > > > > > On Thu, May 30, 2019 at 4:38 PM William Shen <
> > > > > wills...@marinsoftware.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > Currently, the Phoenix site is maintained in and built from
> > SVN
> > > > > > > > > . Not sure
> > what
> > > > > level
> > > > > > > of
> > > > > > > > > work it would require, but does it make sense to move the
> > > source
> > > > > from
> > > > > > > svn
> > > > > > > > > to git, so contribution to the website can follow the same
> > > > JIRA/git
> > > > > > > > > workflow as the rest of the project? It could also make
> sure
> > > > > changes to
> > > > > > > > > Phoenix code are checked in with corresponding
> documentation
> > > > > changes
> > > > > > > when
> > > > > > > > > needed.
> > > > > > > > >
> > > > > > > > > - Will
> > > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > >
> > > > > > > > Swaroopa Kadam
> > > > > > > > [image: https://]about.me/swaroopa_kadam
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Resolved] (PHOENIX-5314) Add Presto connector link to website

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5314.
---
Resolution: Fixed

> Add Presto connector link to website
> 
>
> Key: PHOENIX-5314
> URL: https://issues.apache.org/jira/browse/PHOENIX-5314
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 5.1.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Minor
> Attachments: publish.diff, website_presto_connector.patch
>
>
> Add a link under Addons



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5314) Add Presto connector link to website

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5314:
--
Attachment: website_presto_connector.patch

> Add Presto connector link to website
> 
>
> Key: PHOENIX-5314
> URL: https://issues.apache.org/jira/browse/PHOENIX-5314
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 5.1.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Minor
> Attachments: publish.diff, website_presto_connector.patch
>
>
> Add a link under Addons



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5314) Add Presto connector link to website

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5314:
--
Attachment: publish.diff

> Add Presto connector link to website
> 
>
> Key: PHOENIX-5314
> URL: https://issues.apache.org/jira/browse/PHOENIX-5314
> Project: Phoenix
>  Issue Type: Task
>Affects Versions: 5.1.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Minor
> Attachments: publish.diff, website_presto_connector.patch
>
>
> Add a link under Addons



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5314) Add Presto connector link to website

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5314:
-

 Summary: Add Presto connector link to website
 Key: PHOENIX-5314
 URL: https://issues.apache.org/jira/browse/PHOENIX-5314
 Project: Phoenix
  Issue Type: Task
Affects Versions: 5.1.0
Reporter: Vincent Poon
Assignee: Vincent Poon
 Attachments: publish.diff, website_presto_connector.patch

Add a link under Addons



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5312) Publish official Phoenix docker image

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5312:
-

 Summary: Publish official Phoenix docker image
 Key: PHOENIX-5312
 URL: https://issues.apache.org/jira/browse/PHOENIX-5312
 Project: Phoenix
  Issue Type: Wish
Affects Versions: 5.1.0
Reporter: Vincent Poon


Provide a canonical image to make it easy for new users to download and 
immediately run and play around with Phoenix.
This is also the first step in using tools like 
[docker-client|https://github.com/spotify/docker-client] to run integration 
tests against a docker image.
Other projects like the Presto-phoenix connector could then also execute tests 
against released images.

Ideally, we publish the image on docker hub as an ["Official 
Image"|https://docs.docker.com/docker-hub/official_images/]




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-5231) Configurable Stats Cache

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5231.
---
Resolution: Fixed

Pushed addendum to 4.x and master branches

> Configurable Stats Cache
> 
>
> Key: PHOENIX-5231
> URL: https://issues.apache.org/jira/browse/PHOENIX-5231
> Project: Phoenix
>  Issue Type: Test
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, 
> 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, 
> PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch
>
>  Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Currently, the phoenix stats cache is per 
> ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached 
> entry (the guideposts) and waste resources if these separate connections are 
> querying the same underlying table. It would be good to be able to provide a 
> configurable stats cache as control the cache level so it could be per JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New committer Swaroopa Kadam

[Vincent Poon]

Congrats Swaroopa, looking forward to more patches

On Tue, May 28, 2019 at 4:33 PM Xu Cang 
wrote:

> Congrats! :)
>
> On Tue, May 28, 2019 at 4:18 PM Priyank Porwal 
> wrote:
>
> > Congrats Swaroopa!
> >
> > On Tue, May 28, 2019, 3:24 PM Andrew Purtell 
> wrote:
> >
> > > Congratulations Swaroopa!
> > >
> > > On Tue, May 28, 2019 at 2:38 PM Geoffrey Jacoby 
> > > wrote:
> > >
> > > > On behalf of the Apache Phoenix PMC, I am pleased to announce that
> > > Swaroopa
> > > > Kadam has accepted our invitation to become a Phoenix committer.
> > Swaroopa
> > > > has contributed to a number of areas in the project, including the
> > query
> > > > server[1] and been an active participant in many code reviews for
> > others'
> > > > patches.
> > > >
> > > > Congratulations, Swaroopa, and we look forward to many more great
> > > > contributions from you!
> > > >
> > > > Geoffrey Jacoby
> > > >
> > > > [1] -
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20status%20%3D%20Resolved%20AND%20assignee%20in%20(swaroopa)
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrew
> > >
> > > Words like orphans lost among the crosstalk, meaning torn from truth's
> > > decrepit hands
> > >- A23, Crosstalk
> > >
> >
>

[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5231:
--
Attachment: 5231-services-fix.patch

> Configurable Stats Cache
> 
>
> Key: PHOENIX-5231
> URL: https://issues.apache.org/jira/browse/PHOENIX-5231
> Project: Phoenix
>  Issue Type: Test
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, 
> 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, 
> PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch
>
>  Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Currently, the phoenix stats cache is per 
> ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached 
> entry (the guideposts) and waste resources if these separate connections are 
> querying the same underlying table. It would be good to be able to provide a 
> configurable stats cache as control the cache level so it could be per JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5231:
--
Attachment: (was: 5231-services-fix.patch)

> Configurable Stats Cache
> 
>
> Key: PHOENIX-5231
> URL: https://issues.apache.org/jira/browse/PHOENIX-5231
> Project: Phoenix
>  Issue Type: Test
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, 
> 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, 
> PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch
>
>  Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Currently, the phoenix stats cache is per 
> ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached 
> entry (the guideposts) and waste resources if these separate connections are 
> querying the same underlying table. It would be good to be able to provide a 
> configurable stats cache as control the cache level so it could be per JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5231) Configurable Stats Cache

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5231:
--
Attachment: 5231-services-fix.patch

> Configurable Stats Cache
> 
>
> Key: PHOENIX-5231
> URL: https://issues.apache.org/jira/browse/PHOENIX-5231
> Project: Phoenix
>  Issue Type: Test
>Reporter: Daniel Wong
>Assignee: Daniel Wong
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: 5231-quickfix-v2.txt, 5231-quickfix.txt, 
> 5231-services-fix.patch, PHOENIX-5231.4.x-HBase-1.3.patch, 
> PHOENIX-5231.4.x-HBase-1.3.v2.patch, PHOENIX-5231.4.x-HBase-1.3.v3.patch, 
> PHOENIX-5231.master.v3.patch, PHOENIX-5231.master.v4.patch
>
>  Time Spent: 8h 40m
>  Remaining Estimate: 0h
>
> Currently, the phoenix stats cache is per 
> ConnectionQuerySerivce/ConnectionProfile, which leads to duplicated cached 
> entry (the guideposts) and waste resources if these separate connections are 
> querying the same underlying table. It would be good to be able to provide a 
> configurable stats cache as control the cache level so it could be per JVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5302) Different isNamespaceMappingEnabled for server / client causes TableNotFoundException

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5302:
-

 Summary: Different isNamespaceMappingEnabled for server / client 
causes TableNotFoundException
 Key: PHOENIX-5302
 URL: https://issues.apache.org/jira/browse/PHOENIX-5302
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.14.2
Reporter: Vincent Poon


Scenario:
1)  Fresh cluster start with server isNamespaceMappingEnabled=true.
2)  Client connects with isNamespaceMappingEnabled=false.  Expected exception 
thrown ("Inconsistent namespace mapping")
3)  Client connects with isNamespaceMappingEnabled=true.  Exception: "Table 
undefined. tableName=SYSTEM.CATALOG"



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [VOTE] Release of Apache Phoenix 4.14.2 RC2

[Vincent Poon]

I think we need to keep the file in the /dist/release/phoenix directory
because that's where the final binaries will be downloaded from, and where
KEYS is expected to be found.
I think the dev and release KEYS were probably meant to stay in sync, they
just accidentally got out of sync.

If we only want one then I'd say put everything in the release KEYS.

On Fri, May 24, 2019 at 2:09 PM Thomas D'Silva
 wrote:

> The sample VOTE email in "How to do a release"
> https://phoenix.apache.org/release.html references the KEYS in the dev
> folder.
> I think some of the older VOTE emails refer to KEYS file in the release
> folder, I will remove that file since the KEYS file in dev is a superset.
> I think the comparison of sha512 values is case insensitive so it should be
> fine.
>
>
>
>
> On Fri, May 24, 2019 at 1:24 PM Artem Ervits 
> wrote:
>
> > vote: 4.14.2 RC2-HBase-1.4
> > +1 (non-binding)
> >
> > signatures and sums for src and bin: OK
> > installed on pseudodistributed hadoop 2.8.5 with hbase 1.4.10RC0: OK
> > sqlline various commands: OK
> > compile from src java-1.8.0-openjdk-1.8.0.212.b04-0: OK
> > build with tests: OK
> > performance.py 1M: OK
> >
> > KEYS are in two locations, maybe we should remove one?
> > https://dist.apache.org/repos/dist/release/phoenix/KEYS
> > https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> >
> > looks like Dev keys are superset of release.
> >
> > also noticed sha512 for source is identical but one is uppercase and the
> > other is lower.
> >
> > 1c1,3
> > <
> >
> >
> eb8cf8553a53a0732e4717f5d523a23f9432a6f5eb3769dc330c4e75999460ce36cbe6e21908ecb7cbf05089e6214682bce634e1f3274205cb13f1bfcb8683fe
> > *apache-phoenix-4.14.2-HBase-1.4-src.tar.gz
> > ---
> > > apache-phoenix-4.14.2-HBase-1.4-src.tar.gz:
> > > EB8CF855 3A53A073 2E4717F5 D523A23F 9432A6F5 EB3769DC 330C4E75 999460CE
> > 36CBE6E2
> > >  1908ECB7 CBF05089 E6214682 BCE634E1 F3274205 CB13F1BF CB8683FE
> >
> >
> > On Fri, May 24, 2019 at 2:59 PM Vincent Poon 
> > wrote:
> >
> > > +1
> > > deployed locally on pseudo-distributed cluster, ran some basic sanity
> > tests
> > >
> > >
> > > On Fri, May 24, 2019 at 11:50 AM Andrew Purtell 
> > > wrote:
> > >
> > > > Let me raise this on dev@hbase
> > > >
> > > > On Fri, May 24, 2019 at 11:45 AM Thomas D'Silva
> > > >  wrote:
> > > >
> > > > > We can't commit PHOENIX-5269 to 4.14-HBase-1.3 until HBase 1.3.5 is
> > > > > released.
> > > > >
> > > > > On Fri, May 24, 2019 at 5:21 AM Mihir Monani <
> monani.mi...@gmail.com
> > >
> > > > > wrote:
> > > > >
> > > > > > I think we can't commit this patch to 4.14.2-HBase-1.3 as hbase
> is
> > > not
> > > > > > release from branch-1.3 yet. Last release was 1.3.4
> > > > > > <https://github.com/apache/hbase/tree/rel/1.3.4> on April 15 and
> > > > > > HBASE-22374 was committed on May 9 .
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, May 24, 2019 at 5:35 PM Mihir Monani <
> > monani.mi...@gmail.com
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On checking further, PHOENIX-5269 is committed to
> 4.14-HBase-1.4,
> > > but
> > > > > > it's
> > > > > > > not committed to 4.14.-HBase-1.3 version.
> > > > > > >
> > > > > > > On Fri, May 24, 2019 at 5:24 PM Mihir Monani <
> > > monani.mi...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > >> Should we wait for PHOENIX-5269? I think it would be commited
> in
> > > 1-2
> > > > > > >> days.
> > > > > > >>
> > > > > > >> On Fri, May 24, 2019 at 5:57 AM la...@apache.org <
> > > la...@apache.org>
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>>  +1 again based on inspection of the release artifacts.
> > > > > > >>>
> > > > > > >>> On Thursday, May 23, 2019, 2:09:52 PM PDT, Thomas
> D'Silva <
> > > > > > >>> tdsi...@salesforce.com.INVALID> wrote:
> > > > > > >>

Re: [VOTE] Release of Apache Phoenix 4.14.2 RC2

[Vincent Poon]

+1
deployed locally on pseudo-distributed cluster, ran some basic sanity tests


On Fri, May 24, 2019 at 11:50 AM Andrew Purtell  wrote:

> Let me raise this on dev@hbase
>
> On Fri, May 24, 2019 at 11:45 AM Thomas D'Silva
>  wrote:
>
> > We can't commit PHOENIX-5269 to 4.14-HBase-1.3 until HBase 1.3.5 is
> > released.
> >
> > On Fri, May 24, 2019 at 5:21 AM Mihir Monani 
> > wrote:
> >
> > > I think we can't commit this patch to 4.14.2-HBase-1.3 as hbase is not
> > > release from branch-1.3 yet. Last release was 1.3.4
> > >  on April 15 and
> > > HBASE-22374 was committed on May 9 .
> > >
> > >
> > >
> > > On Fri, May 24, 2019 at 5:35 PM Mihir Monani 
> > > wrote:
> > >
> > > > On checking further, PHOENIX-5269 is committed to 4.14-HBase-1.4, but
> > > it's
> > > > not committed to 4.14.-HBase-1.3 version.
> > > >
> > > > On Fri, May 24, 2019 at 5:24 PM Mihir Monani  >
> > > > wrote:
> > > >
> > > >> Should we wait for PHOENIX-5269? I think it would be commited in 1-2
> > > >> days.
> > > >>
> > > >> On Fri, May 24, 2019 at 5:57 AM la...@apache.org 
> > > >> wrote:
> > > >>
> > > >>>  +1 again based on inspection of the release artifacts.
> > > >>>
> > > >>> On Thursday, May 23, 2019, 2:09:52 PM PDT, Thomas D'Silva <
> > > >>> tdsi...@salesforce.com.INVALID> wrote:
> > > >>>
> > > >>>  Hello Everyone,
> > > >>>
> > > >>> This is a call for a vote on Apache Phoenix 4.14.2 RC2. This is a
> > patch
> > > >>> release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
> > > 1.4.
> > > >>> The release includes both a source-only release and a convenience
> > > binary
> > > >>> release for each supported HBase version.
> > > >>>
> > > >>> This release has feature parity with supported HBase versions and
> > > >>> includes
> > > >>> several critical bug fixes.
> > > >>>
> > > >>> The source tarball, including signatures, digests, etc can be found
> > at:
> > > >>>
> > > >>>
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc2/src/
> > > >>>
> > > >>>
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc2/src/
> > > >>>
> > > >>> The binary artifacts can be found at:
> > > >>>
> > > >>>
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc2/bin/
> > > >>>
> > > >>>
> > >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc2/bin/
> > > >>>
> > > >>> For a complete list of changes, see:
> > > >>>
> > > >>>
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12344379
> > > >>>
> > > >>> Artifacts are signed with my "CODE SIGNING KEY": DFD86C02
> > > >>>
> > > >>> KEYS file available here:
> > > >>> https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> > > >>>
> > > >>> The hash and tag to be voted upon:
> > > >>>
> > > >>>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=13ce47cf4214c9c78e8fec5f96fb861410677817
> > > >>>
> > > >>>
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=a86206a006c85afd5884a015d6fe452d823ac626
> > > >>>
> > > >>> Vote will be open for at least 72 hours. Please vote:
> > > >>>
> > > >>> [ ] +1 approve
> > > >>> [ ] +0 no opinion
> > > >>> [ ] -1 disapprove (and reason why)
> > > >>>
> > > >>> Thanks,
> > > >>> The Apache Phoenix Team
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Mihir Monani
> > > >> (+91)-9429473434
> > > >>
> > > >
> > > >
> > > > --
> > > > Mihir Monani
> > > > (+91)-9429473434
> > > >
> > >
> > >
> > > --
> > > Mihir Monani
> > > (+91)-9429473434
> > >
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [DISCUSS] Drop support for HBase-1.2

[Vincent Poon]

+1

On Sun, May 12, 2019 at 8:18 PM Andrew Purtell 
wrote:

> +1
>
> I would think it would be a drain on committer time to keep having to
> accommodate interface differences on the EOL line.
>
> > On May 10, 2019, at 1:28 PM, Thomas D'Silva 
> wrote:
> >
> > Since HBase 1.2 is now end of life and we are creating a new branch to
> > support HBase-1.5(PHOENIX-5277), I think we should drop the HBase-1.2
> > branches. What do folks think?
> >
> > Thanks,
> > Thomas
>

[jira] [Resolved] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5213.
---
   Resolution: Fixed
Fix Version/s: 5.1.0
   4.15.0

Pushed to master and 4.x branches

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v4.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.
> 5) rename the jar to match the final name in the repository:  
> phoenix-client-{version}.jar  There is now a symlink 
> phoenix-{version}-client.jar to maintain backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: (was: PHOENIX-5213.4.x-HBase-1.4.v4.patch)

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v4.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.
> 5) rename the jar to match the final name in the repository:  
> phoenix-client-{version}.jar  There is now a symlink 
> phoenix-{version}-client.jar to maintain backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v4.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v4.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.
> 5) rename the jar to match the final name in the repository:  
> phoenix-client-{version}.jar  There is now a symlink 
> phoenix-{version}-client.jar to maintain backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v4.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v4.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.
> 5) rename the jar to match the final name in the repository:  
> phoenix-client-{version}.jar  There is now a symlink 
> phoenix-{version}-client.jar to maintain backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Description: 
To make the existing phoenix-client, I'm proposing the following changes:
1)  Add additional relocations of some packages

Add a new "embedded" classifier to phoenix-client that does the following: 
2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
directly from phoenix-core itself, but transitively from other projects.  It's 
generally considered best practice to not impose a log binding on downstream 
projects.  The slf4j-log4j12 jar will still be in the phoenix tarball's /lib 
folder.

3)  Create a source jar for phoenix-client embedded.

4)  Create a dependency-reduced pom, so that the client can be used directly in 
downstream projects without having to exclude transitive artifacts.

5) rename the jar to match the final name in the repository:  
phoenix-client-{version}.jar  There is now a symlink 
phoenix-{version}-client.jar to maintain backwards compatibility.

  was:
To make the existing phoenix-client, I'm proposing the following changes:
1)  Add additional relocations of some packages

Add a new "embedded" classifier to phoenix-client that does the following: 
2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
directly from phoenix-core itself, but transitively from other projects.  It's 
generally considered best practice to not impose a log binding on downstream 
projects.  The slf4j-log4j12 jar will still be in the phoenix tarball's /lib 
folder.

3)  Create a source jar for phoenix-client embedded.

4)  Create a dependency-reduced pom, so that the client can be used directly in 
downstream projects without having to exclude transitive artifacts.


> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.
> 5) rename the jar to match the final name in the repository:  
> phoenix-client-{version}.jar  There is now a symlink 
> phoenix-{version}-client.jar to maintain backwards compatibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v3.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch, PHOENIX-5213.4.x-HBase-1.4.v3.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Description: 
To make the existing phoenix-client, I'm proposing the following changes:
1)  Add additional relocations of some packages

Add a new "embedded" classifier to phoenix-client that does the following: 
2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
directly from phoenix-core itself, but transitively from other projects.  It's 
generally considered best practice to not impose a log binding on downstream 
projects.  The slf4j-log4j12 jar will still be in the phoenix tarball's /lib 
folder.

3)  Create a source jar for phoenix-client embedded.

4)  Create a dependency-reduced pom, so that the client can be used directly in 
downstream projects without having to exclude transitive artifacts.

  was:
To make the existing phoenix-client, I'm proposing the following changes:
1)  Add additional relocations of some packages

2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
directly from phoenix-core itself, but transitively from other projects.  It's 
generally considered best practice to not impose a log binding on downstream 
projects.  The slf4j-log4j12 jar will still be in the phoenix tarball's /lib 
folder.

3)  Changing the jar naming from phoenix\-\[version\]\-client.jar to 
phoenix-client-\[version\].jar
The reason for this is that there is no way, AFAIK, to change the naming 
convention in maven's repo.  You can change the jar name locally, but when it 
gets installed to the repo, it always has to follow the artfiactname-version 
naming convention.  To avoid confusion of having two separate jar file names, I 
propose we just change it to Maven's convention so we can publish releases of 
phoenix-client.

4)  Create a source jar for phoenix-client.

5)  Create a dependency-reduced pom, so that the client can be used directly in 
downstream projects without having to exclude transitive artifacts.


> Phoenix-client improvements:  add more relocations, exclude log binding, 
> change naming
> --
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, add source jar

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Summary: Phoenix-client improvements:  add more relocations, exclude log 
binding, add source jar  (was: Phoenix-client improvements:  add more 
relocations, exclude log binding, change naming)

> Phoenix-client improvements:  add more relocations, exclude log binding, add 
> source jar
> ---
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> Add a new "embedded" classifier to phoenix-client that does the following: 
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Create a source jar for phoenix-client embedded.
> 4)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New Phoenix PMC member: Geoffrey Jacoby

[Vincent Poon]

Congrats Geoffrey!

On Tue, Apr 9, 2019 at 11:42 AM Thomas D'Silva  wrote:

> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Geoffrey
> Jacoby has accepted our invitation to join the PMC.
>
> Please join me in congratulating Geoffrey.
>
> Thanks,
> Thomas
>

Re: [ANNOUNCE] New Phoenix PMC member: Cheng Lei

[Vincent Poon]

Congrats Cheng!

On Tue, Apr 9, 2019 at 11:42 AM Thomas D'Silva  wrote:

> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Cheng
> Lei has accepted our invitation to join the PMC.
>
> Please join me in congratulating Cheng.
>
> Thanks,
> Thomas
>

Re: [ANNOUNCE] New Phoenix committer: Abhishek Singh Chouhan

[Vincent Poon]

Congratulations Abhishek!

On Fri, Apr 5, 2019 at 10:46 AM Thomas D'Silva  wrote:

> On behalf of the Apache Phoenix PMC, I am pleased to announce that
> Abhishek Singh
> Chouhan has accepted our invitation to become a committer. Abhishek has
> fixed several bugs[1] (including an important one related to server side
> sorting).
>
> Please welcome him to the Apache Phoenix team.
>
> Thank you,
> Thomas
>
> [1]
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20assignee%3D%22abhishek.chouhan%22%20AND%20status%3DResolved
>

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v2.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, 
> change naming
> --
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Changing the jar naming from phoenix\-\[version\]\-client.jar to 
> phoenix-client-\[version\].jar
> The reason for this is that there is no way, AFAIK, to change the naming 
> convention in maven's repo.  You can change the jar name locally, but when it 
> gets installed to the repo, it always has to follow the artfiactname-version 
> naming convention.  To avoid confusion of having two separate jar file names, 
> I propose we just change it to Maven's convention so we can publish releases 
> of phoenix-client.
> 4)  Create a source jar for phoenix-client.
> 5)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: (was: PHOENIX-5213.4.x-HBase-1.4.v2.patch)

> Phoenix-client improvements:  add more relocations, exclude log binding, 
> change naming
> --
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Changing the jar naming from phoenix\-\[version\]\-client.jar to 
> phoenix-client-\[version\].jar
> The reason for this is that there is no way, AFAIK, to change the naming 
> convention in maven's repo.  You can change the jar name locally, but when it 
> gets installed to the repo, it always has to follow the artfiactname-version 
> naming convention.  To avoid confusion of having two separate jar file names, 
> I propose we just change it to Maven's convention so we can publish releases 
> of phoenix-client.
> 4)  Create a source jar for phoenix-client.
> 5)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v2.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, 
> change naming
> --
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5213.4.x-HBase-1.4.v2.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Changing the jar naming from phoenix\-\[version\]\-client.jar to 
> phoenix-client-\[version\].jar
> The reason for this is that there is no way, AFAIK, to change the naming 
> convention in maven's repo.  You can change the jar name locally, but when it 
> gets installed to the repo, it always has to follow the artfiactname-version 
> naming convention.  To avoid confusion of having two separate jar file names, 
> I propose we just change it to Maven's convention so we can publish releases 
> of phoenix-client.
> 4)  Create a source jar for phoenix-client.
> 5)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5214) Cleanup phoenix-core pom

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5214:
--
Attachment: PHOENIX-5214.4.x-HBase-1.4.v1.patch

> Cleanup phoenix-core pom
> 
>
> Key: PHOENIX-5214
> URL: https://issues.apache.org/jira/browse/PHOENIX-5214
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5214.4.x-HBase-1.4.v1.patch
>
>
> 1) Remove version numbers when already specified in base pom's 
> dependencyManagement section
> 2) Change sqlline scope to 'runtime' since we don't need it to actually 
> compile.  (technically this shouldn't be in the pom and should be an assembly 
> thing that gets added to a tarball, but that's another jira for another 
> day...)
> 3) Change findbugs scope to 'provided' - we don't need this beyond 
> compiling/testing
> 4)  Remove hbase-annotations and hadoop-annotations.  We don't seem to be 
> using these anywhere.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (PHOENIX-5214) Cleanup phoenix-core pom

[Vincent Poon (JIRA)]

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

Vincent Poon reassigned PHOENIX-5214:
-

Assignee: Vincent Poon

> Cleanup phoenix-core pom
> 
>
> Key: PHOENIX-5214
> URL: https://issues.apache.org/jira/browse/PHOENIX-5214
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
>
> 1) Remove version numbers when already specified in base pom's 
> dependencyManagement section
> 2) Change sqlline scope to 'runtime' since we don't need it to actually 
> compile.  (technically this shouldn't be in the pom and should be an assembly 
> thing that gets added to a tarball, but that's another jira for another 
> day...)
> 3) Change findbugs scope to 'provided' - we don't need this beyond 
> compiling/testing
> 4)  Remove hbase-annotations and hadoop-annotations.  We don't seem to be 
> using these anywhere.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5214) Cleanup phoenix-core pom

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5214:
-

 Summary: Cleanup phoenix-core pom
 Key: PHOENIX-5214
 URL: https://issues.apache.org/jira/browse/PHOENIX-5214
 Project: Phoenix
  Issue Type: Improvement
Affects Versions: 5.0.0, 4.15.0
Reporter: Vincent Poon


1) Remove version numbers when already specified in base pom's 
dependencyManagement section

2) Change sqlline scope to 'runtime' since we don't need it to actually 
compile.  (technically this shouldn't be in the pom and should be an assembly 
thing that gets added to a tarball, but that's another jira for another day...)

3) Change findbugs scope to 'provided' - we don't need this beyond 
compiling/testing

4)  Remove hbase-annotations and hadoop-annotations.  We don't seem to be using 
these anywhere.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5213:
--
Attachment: PHOENIX-5213.4.x-HBase-1.4.v1.patch

> Phoenix-client improvements:  add more relocations, exclude log binding, 
> change naming
> --
>
> Key: PHOENIX-5213
> URL: https://issues.apache.org/jira/browse/PHOENIX-5213
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Vincent Poon
>    Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
> directly from phoenix-core itself, but transitively from other projects.  
> It's generally considered best practice to not impose a log binding on 
> downstream projects.  The slf4j-log4j12 jar will still be in the phoenix 
> tarball's /lib folder.
> 3)  Changing the jar naming from phoenix-[version]-client.jar to 
> phoenix-client-[version].jar
> The reason for this is that there is no way, AFAIK, to change the naming 
> convention in maven's repo.  You can change the jar name locally, but when it 
> gets installed to the repo, it always has to follow the artfiactname-version 
> naming convention.  To avoid confusion of having two separate jar file names, 
> I propose we just change it to Maven's convention so we can publish releases 
> of phoenix-client.
> 4)  Create a source jar for phoenix-client.
> 5)  Create a dependency-reduced pom, so that the client can be used directly 
> in downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5213:
-

 Summary: Phoenix-client improvements:  add more relocations, 
exclude log binding, change naming
 Key: PHOENIX-5213
 URL: https://issues.apache.org/jira/browse/PHOENIX-5213
 Project: Phoenix
  Issue Type: Improvement
Affects Versions: 5.0.0, 4.15.0
Reporter: Vincent Poon
Assignee: Vincent Poon


To make the existing phoenix-client, I'm proposing the following changes:
1)  Add additional relocations of some packages

2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in 
directly from phoenix-core itself, but transitively from other projects.  It's 
generally considered best practice to not impose a log binding on downstream 
projects.  The slf4j-log4j12 jar will still be in the phoenix tarball's /lib 
folder.

3)  Changing the jar naming from phoenix-[version]-client.jar to 
phoenix-client-[version].jar
The reason for this is that there is no way, AFAIK, to change the naming 
convention in maven's repo.  You can change the jar name locally, but when it 
gets installed to the repo, it always has to follow the artfiactname-version 
naming convention.  To avoid confusion of having two separate jar file names, I 
propose we just change it to Maven's convention so we can publish releases of 
phoenix-client.

4)  Create a source jar for phoenix-client.

5)  Create a dependency-reduced pom, so that the client can be used directly in 
downstream projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-3082) timestamp function display wrong output

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-3082.
---
Resolution: Cannot Reproduce

Can't repro this, feel free to reopen if you can repro it

> timestamp function display wrong output
> ---
>
> Key: PHOENIX-3082
> URL: https://issues.apache.org/jira/browse/PHOENIX-3082
> Project: Phoenix
>  Issue Type: Bug
>Reporter: qinzl
>Priority: Major
>
> when i input : select now() ; or select CURRENT_DATE ( )
> the result is :
> 292278994-08-17 07:12:55.807   
> the year display is not correct



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (PHOENIX-5139) PhoenixDriver lockInterruptibly usage could unlock without locking

[Vincent Poon (JIRA)]

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

Vincent Poon reassigned PHOENIX-5139:
-

Assignee: Vincent Poon

> PhoenixDriver lockInterruptibly usage could unlock without locking
> --
>
> Key: PHOENIX-5139
> URL: https://issues.apache.org/jira/browse/PHOENIX-5139
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0, 5.1.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5139.4.x-HBase-1.4.v1.patch
>
>
> We have calls to lockInterruptibly surrounded by a finally call to unlock, 
> but there's a chance InterruptedException was thrown and we didn't obtain the 
> lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5139) PhoenixDriver lockInterruptibly usage could unlock without locking

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5139:
--
Attachment: PHOENIX-5139.4.x-HBase-1.4.v1.patch

> PhoenixDriver lockInterruptibly usage could unlock without locking
> --
>
> Key: PHOENIX-5139
> URL: https://issues.apache.org/jira/browse/PHOENIX-5139
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0, 5.1.0
>    Reporter: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5139.4.x-HBase-1.4.v1.patch
>
>
> We have calls to lockInterruptibly surrounded by a finally call to unlock, 
> but there's a chance InterruptedException was thrown and we didn't obtain the 
> lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5139) PhoenixDriver lockInterruptibly usage could unlock without locking

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5139:
-

 Summary: PhoenixDriver lockInterruptibly usage could unlock 
without locking
 Key: PHOENIX-5139
 URL: https://issues.apache.org/jira/browse/PHOENIX-5139
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.15.0, 5.1.0
Reporter: Vincent Poon


We have calls to lockInterruptibly surrounded by a finally call to unlock, but 
there's a chance InterruptedException was thrown and we didn't obtain the lock.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DRAFT] board report feb 2019

[Vincent Poon]

+1

On Tue, Feb 5, 2019 at 11:03 AM Thomas D'Silva
 wrote:

> LGTM
>
> On Tue, Feb 5, 2019 at 8:41 AM Josh Elser  wrote:
>
> > All,
> >
> > Please take the time to review what I have below and propose any
> > additions/modifications you think appropriate. Unless I hear requests
> > otherwise, I'll submit this Monday (2019/02/11).
> >
> > For those who have the karma and appreciate the prior context, you can
> > see our previous reports at
> > https://whimsy.apache.org/board/minutes/Phoenix.html
> >
> > Thanks in advance!
> >
> > - Josh
> >
> > 
> > ## Description:
> >   - Apache Phoenix enables SQL-based OLTP and operational analytics for
> > Apache Hadoop
> >
> > ## Issues:
> >   - There are no issues requiring board attention at this time
> >
> > ## Activity:
> >   - 4.14.1 was officially released. This release was in the final steps
> > of release at the time of that last board report (Nov 2018).
> >   - We've added a new PMC member and new committers! Karan was added
> > as a PMC member. Four new committers joined our ranks: Akshita,
> > Chinmay, Jaanai, and Gerald.
> >   - Regular development continues on the 4.x release line. The 5.x would
> > benefit from a new release in the near future.
> >
> > ## Health report:
> >   - Activity remains constant on average. We had an expected tail-off
> > during the Christmas and (calendar) New Year with our predominantly
> > US-based membership.
> >
> > ## PMC changes:
> >   - Currently 28 PMC members.
> >   - New PMC members:
> >  - Karan Mehta (2018/12/23)
> >
> > ## Committer base changes:
> >   - Currently 40 committers.
> >   - New committers:
> > - Akshita Malhotra (2019/01/21)
> > - Chinmay Kulkarni (2018/12/10)
> > - Jaanai Zhang (2019/01/02)
> > - Gerald Sangudi   (2018/12/16)
> >
> > ## Releases:
> >   - 4.14.1 was released on 2018/11/14
> >   - 5.0.0 was released on Sat Jul 14 2018
> >
> > ## Mailing list activity:
> >   - Activity is largely in-line with history. No significant changes to
> > trends to be identified.
> > 
> >
>

[jira] [Resolved] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5094.
---
   Resolution: Resolved
Fix Version/s: 5.1.0
   4.15.0

Pushed to master and 4.x branches.  Thanks for the patch [~kiran.maturi] and 
[~mihir6692]

> Index can transition from INACTIVE to ACTIVE via Phoenix Client
> ---
>
> Key: PHOENIX-5094
> URL: https://issues.apache.org/jira/browse/PHOENIX-5094
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Monani Mihir
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch, 
> PHOENIX-5094-4.14-HBase-1.3.02.patch, PHOENIX-5094-4.14-HBase-1.3.03.patch, 
> PHOENIX-5094-4.14-HBase-1.3.04.patch, PHOENIX-5094-4.14-HBase-1.3.05.patch, 
> PHOENIX-5094-master.01.patch, PHOENIX-5094-master.02.patch, 
> PHOENIX-5094-master.03.patch
>
>
> Suppose Index is in INACTIVE state and Client load is running continuously. 
> With INACTIVE State, client will keep maintaining index.
> Before Rebuilder could run and bring index back in sync with data table, If 
> some mutation for Index fails from client side, then client will transition 
> Index state (From INACTIVE--> PENDING_DISABLE).
> If client succeeds in writing mutation in subsequent retries, it will 
> transition Index state again ( From PENDING_DISABLE --> ACTIVE) .
> Above scenario will leave some part of Index out of sync with data table.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter

[Vincent Poon (JIRA)]

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

Vincent Poon reopened PHOENIX-4993:
---

> Data table region should not close RS level shared/cached connections like 
> IndexWriter, RecoveryIndexWriter
> ---
>
> Key: PHOENIX-4993
> URL: https://issues.apache.org/jira/browse/PHOENIX-4993
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, 
> PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, 
> PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, 
> PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, 
> PHOENIX-4993-master.addendum-1.patch
>
>
> Issue is related to Region Server being killed when one region is closing and 
> another region is trying to write index updates.
> When the data table region closes it will close region server level 
> cached/shared connections and it could interrupt other region 
> index/index-state update.
> -- Region1: Closing
> {code:java}
> TrackingParallellWriterIndexCommitter#stop() {
> this.retryingFactory.shutdown();
> this.noRetriesFactory.shutdown();
> }{code}
> closes the cached connections calling 
> CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java
>  
> --Region2: Writing index updates
> Index updates fail as connections are closed, which leads to 
> RejectedExecutionException/Connection being null. This triggers 
> PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the 
> the syscat table using the cached connections. Here it will not be able to 
> reach to SYSCAT , so we will trigger KillServreFailurePolicy.
> CoprocessorHConnectionTableFactory#getTable()
>  
>  
> {code:java}
> if (connection == null || connection.isClosed()) {
> throw new IllegalArgumentException("Connection is null or closed.");
> }{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-4993.
---
Resolution: Resolved

> Data table region should not close RS level shared/cached connections like 
> IndexWriter, RecoveryIndexWriter
> ---
>
> Key: PHOENIX-4993
> URL: https://issues.apache.org/jira/browse/PHOENIX-4993
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, 
> PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, 
> PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, 
> PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, 
> PHOENIX-4993-master.addendum-1.patch
>
>
> Issue is related to Region Server being killed when one region is closing and 
> another region is trying to write index updates.
> When the data table region closes it will close region server level 
> cached/shared connections and it could interrupt other region 
> index/index-state update.
> -- Region1: Closing
> {code:java}
> TrackingParallellWriterIndexCommitter#stop() {
> this.retryingFactory.shutdown();
> this.noRetriesFactory.shutdown();
> }{code}
> closes the cached connections calling 
> CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java
>  
> --Region2: Writing index updates
> Index updates fail as connections are closed, which leads to 
> RejectedExecutionException/Connection being null. This triggers 
> PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the 
> the syscat table using the cached connections. Here it will not be able to 
> reach to SYSCAT , so we will trigger KillServreFailurePolicy.
> CoprocessorHConnectionTableFactory#getTable()
>  
>  
> {code:java}
> if (connection == null || connection.isClosed()) {
> throw new IllegalArgumentException("Connection is null or closed.");
> }{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-4993.
---
Resolution: Fixed

> Data table region should not close RS level shared/cached connections like 
> IndexWriter, RecoveryIndexWriter
> ---
>
> Key: PHOENIX-4993
> URL: https://issues.apache.org/jira/browse/PHOENIX-4993
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, 
> PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, 
> PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, 
> PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch, 
> PHOENIX-4993-master.addendum-1.patch
>
>
> Issue is related to Region Server being killed when one region is closing and 
> another region is trying to write index updates.
> When the data table region closes it will close region server level 
> cached/shared connections and it could interrupt other region 
> index/index-state update.
> -- Region1: Closing
> {code:java}
> TrackingParallellWriterIndexCommitter#stop() {
> this.retryingFactory.shutdown();
> this.noRetriesFactory.shutdown();
> }{code}
> closes the cached connections calling 
> CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java
>  
> --Region2: Writing index updates
> Index updates fail as connections are closed, which leads to 
> RejectedExecutionException/Connection being null. This triggers 
> PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the 
> the syscat table using the cached connections. Here it will not be able to 
> reach to SYSCAT , so we will trigger KillServreFailurePolicy.
> CoprocessorHConnectionTableFactory#getTable()
>  
>  
> {code:java}
> if (connection == null || connection.isClosed()) {
> throw new IllegalArgumentException("Connection is null or closed.");
> }{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-4993.
---
Resolution: Fixed

Pushed to master

> Data table region should not close RS level shared/cached connections like 
> IndexWriter, RecoveryIndexWriter
> ---
>
> Key: PHOENIX-4993
> URL: https://issues.apache.org/jira/browse/PHOENIX-4993
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, 
> PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, 
> PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, 
> PHOENIX-4993-master.01.patch, PHOENIX-4993-master.02.patch
>
>
> Issue is related to Region Server being killed when one region is closing and 
> another region is trying to write index updates.
> When the data table region closes it will close region server level 
> cached/shared connections and it could interrupt other region 
> index/index-state update.
> -- Region1: Closing
> {code:java}
> TrackingParallellWriterIndexCommitter#stop() {
> this.retryingFactory.shutdown();
> this.noRetriesFactory.shutdown();
> }{code}
> closes the cached connections calling 
> CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java
>  
> --Region2: Writing index updates
> Index updates fail as connections are closed, which leads to 
> RejectedExecutionException/Connection being null. This triggers 
> PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the 
> the syscat table using the cached connections. Here it will not be able to 
> reach to SYSCAT , so we will trigger KillServreFailurePolicy.
> CoprocessorHConnectionTableFactory#getTable()
>  
>  
> {code:java}
> if (connection == null || connection.isClosed()) {
> throw new IllegalArgumentException("Connection is null or closed.");
> }{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (PHOENIX-4993) Data table region should not close RS level shared/cached connections like IndexWriter, RecoveryIndexWriter

[Vincent Poon (JIRA)]

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

Vincent Poon reopened PHOENIX-4993:
---

[~kiran.maturi] The master patch caused a build failure.  I've reverted the 
commit for now - can you look into it?

> Data table region should not close RS level shared/cached connections like 
> IndexWriter, RecoveryIndexWriter
> ---
>
> Key: PHOENIX-4993
> URL: https://issues.apache.org/jira/browse/PHOENIX-4993
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.0
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4993-4.x-HBase-1.3.01.patch, 
> PHOENIX-4993-4.x-HBase-1.3.02.patch, PHOENIX-4993-4.x-HBase-1.3.03.patch, 
> PHOENIX-4993-4.x-HBase-1.3.04.patch, PHOENIX-4993-4.x-HBase-1.3.05.patch, 
> PHOENIX-4993-master.01.patch
>
>
> Issue is related to Region Server being killed when one region is closing and 
> another region is trying to write index updates.
> When the data table region closes it will close region server level 
> cached/shared connections and it could interrupt other region 
> index/index-state update.
> -- Region1: Closing
> {code:java}
> TrackingParallellWriterIndexCommitter#stop() {
> this.retryingFactory.shutdown();
> this.noRetriesFactory.shutdown();
> }{code}
> closes the cached connections calling 
> CoprocessorHConnectionTableFactory#shutdown() in ServerUtil.java
>  
> --Region2: Writing index updates
> Index updates fail as connections are closed, which leads to 
> RejectedExecutionException/Connection being null. This triggers 
> PhoenixIndexFailurePolicy#handleFailureWithExceptions that tries to get the 
> the syscat table using the cached connections. Here it will not be able to 
> reach to SYSCAT , so we will trigger KillServreFailurePolicy.
> CoprocessorHConnectionTableFactory#getTable()
>  
>  
> {code:java}
> if (connection == null || connection.isClosed()) {
> throw new IllegalArgumentException("Connection is null or closed.");
> }{code}
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Build failure

[Vincent Poon]

Sorry, will revert for now

On Mon, Jan 28, 2019 at 3:10 PM Gerald Sangudi 
wrote:

> Hi folks,
>
> The build is failing for me on the latest master. I also tried a fresh
> install.
>
> The latest commit that's failing is
>
> https://github.com/apache/phoenix/commit/1455763b43cc71bff9e69daf928be59251e97235
>
> The first error is a dependency on a HBase class that's not included in
> Phoenix.
>
> Previous commits work fine for me.
>
> Thanks,
> Gerald
>

[jira] [Updated] (PHOENIX-5103) Can't create/drop table using 4.14 client against 4.15 server

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5103:
--
Priority: Blocker  (was: Major)

> Can't create/drop table using 4.14 client against 4.15 server
> -
>
> Key: PHOENIX-5103
> URL: https://issues.apache.org/jira/browse/PHOENIX-5103
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>    Reporter: Vincent Poon
>Priority: Blocker
>
> server is running 4.15 commit e3280f
> Connect with 4.14.1 client.  Create table gives this:
> Caused by: 
> org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.TableNotFoundException):
>  org.apache.hadoop.hbase.TableNotFoundException: Table 'SYSTEM:CHILD_LINK' 
> was not found, got: SYSTEM:CATALOG.
>   at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1362)
>   at 
> org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1230)
>   at 
> org.apache.hadoop.hbase.client.CoprocessorHConnection.locateRegion(CoprocessorHConnection.java:41)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5103) Can't create/drop table using 4.14 client against 4.15 server

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5103:
-

 Summary: Can't create/drop table using 4.14 client against 4.15 
server
 Key: PHOENIX-5103
 URL: https://issues.apache.org/jira/browse/PHOENIX-5103
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.15.0
Reporter: Vincent Poon


server is running 4.15 commit e3280f
Connect with 4.14.1 client.  Create table gives this:

Caused by: 
org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.TableNotFoundException):
 org.apache.hadoop.hbase.TableNotFoundException: Table 'SYSTEM:CHILD_LINK' was 
not found, got: SYSTEM:CATALOG.
at 
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegionInMeta(ConnectionManager.java:1362)
at 
org.apache.hadoop.hbase.client.ConnectionManager$HConnectionImplementation.locateRegion(ConnectionManager.java:1230)
at 
org.apache.hadoop.hbase.client.CoprocessorHConnection.locateRegion(CoprocessorHConnection.java:41)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5095) Support INTERLEAVE of parent and child tables

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5095:
-

 Summary: Support INTERLEAVE of parent and child tables
 Key: PHOENIX-5095
 URL: https://issues.apache.org/jira/browse/PHOENIX-5095
 Project: Phoenix
  Issue Type: Improvement
Affects Versions: 4.15.0
Reporter: Vincent Poon


Spanner has a concept of [interleaved 
tables|https://cloud.google.com/spanner/docs/schema-and-data-model#creating-interleaved-tables]

I'd like to brainstorm here how to implement this in Phoenix.  In general we 
want a design that can have
1) Fast queries against the parent table PK
2) Fast queries against the child table PK
3) Fast joins between the parent and child

It seems we can get pretty close to this with views.  Views can have their own 
PK which adds to the rowkey of the base table.  However, there doesn't seem to 
be a delimiter to distinguish PKs of different views on the base table.  The 
closest I could up with is adding a delimiter to the base table PK, something 
like:
CREATE TABLE IF NOT EXISTS Singers (
SingerId BIGINT NOT NULL,
Delimiter CHAR(10) NOT NULL,
FirstName VARCHAR,
CONSTRAINT PK PRIMARY KEY
(
SingerId,
Delimiter
)
);
CREATE VIEW Albums (AlbumId BIGINT PRIMARY KEY, AlbumTitle VARCHAR) AS SELECT * 
from Singers where Delimiter = 'Albums';

We also need to make the JOIN on these tables more intelligent, such that a 
single scan can join across parent-child.  Perhaps by reading metadata created 
during INTERLEAVE table creation, so we know we are joining across interleaved 
tables.

We could also have a custom split policy to avoid splitting in the middle of an 
interleaved table (though this might restrict how large your interleaved child 
table can be).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] phoenix-connectors and phoenix-queryserver release process

[Vincent Poon]

Right now the "presto connector" I'm working on also builds an uber jar
that is like phoenix-client but with some additional excludes and
relocations.  So I would need to build one for each Phoenix release.  So I
was thinking of something like:
phoenix-client-4.14.1-HBase-1.4-presto-1.0.0.jar

I would think it would be the same for e.g. PQS, if we ultimately want to
build a tarball that includes everything you need to run PQS, which is the
easiest thing for users.  You need a specific Phoenix client version to
include in the bundle.

Yet at the same time, we want to avoid having many branches like Phoenix.

So maybe we can just have a single master branch, and have a 'target'
Phoenix version as a variable, with a default of the latest Phoenix release.
Then at release time we can deploy with different Phoenix version targets
as needed.

On Tue, Jan 8, 2019 at 12:50 PM Josh Elser  wrote:

> +1 for queryserver starting out at 1.0.0, for sure. We've really made
> only a few changes for PQS over the years (the majority of code is in
> Avatica). Doesn't make sense to follow the 'normal' Phoenix versioning.
>
> Assuming the connectors is similarly slow moving, I'm in favor of the
> same for that too.
>
> I asked on the PR for the queryserver repo: how are people going to
> interact with these? Something as simple as:
>
> * How will PQS know where the phoenix-client.jar is?
> * Where do users invoke sqlline-thin.py from?
>
> On 1/8/19 2:34 PM, Thomas D'Silva wrote:
> > We are currently working on moving the connectors and queryserver to
> their
> > own repos (see https://issues.apache.org/jira/browse/PHOENIX-5062 and
> > https://issues.apache.org/jira/browse/PHOENIX-5063).
> > IMO we should have a single branch for each repo that depends on a
> released
> > version of Phoenix/HBase. I thinnk we should start the pom versions at
> > 1.0.0. We can then have connectors or queryserver releases independent of
> > Phoenix. For the connectors, I think we should release all of them when
> we
> > have a connector release. Same with queryserver (release both the server
> > and client).
> > What do folks think?
> >
>

[jira] [Updated] (PHOENIX-5088) Generate source jar and reduced pom for phoenix-client

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5088:
--
Attachment: PHOENIX-5088.4.x-HBase-1.4.v1.patch

> Generate source jar and reduced pom for phoenix-client
> --
>
> Key: PHOENIX-5088
> URL: https://issues.apache.org/jira/browse/PHOENIX-5088
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.15.0
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Minor
> Attachments: PHOENIX-5088.4.x-HBase-1.4.v1.patch
>
>
> Other projects may include phoenix-client as a dependency.  For convenience, 
> we should generate the sources jar and dependency-reduced-pom.xml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5088) Generate source jar and reduced pom for phoenix-client

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5088:
-

 Summary: Generate source jar and reduced pom for phoenix-client
 Key: PHOENIX-5088
 URL: https://issues.apache.org/jira/browse/PHOENIX-5088
 Project: Phoenix
  Issue Type: Improvement
Affects Versions: 4.15.0
Reporter: Vincent Poon
Assignee: Vincent Poon


Other projects may include phoenix-client as a dependency.  For convenience, we 
should generate the sources jar and dependency-reduced-pom.xml.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [ANNOUNCE] New Phoenix PMC member: Karan Mehta

[Vincent Poon]

Congrats Karan!

On Wed, Dec 12, 2018 at 9:17 AM Andrew Purtell  wrote:

> Congratulations and welcome, Karan.
>
> On Tue, Dec 11, 2018 at 8:38 PM Thomas D'Silva  wrote:
>
> > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Karan
> > Mehta has accepted our invitation to join the PMC. He has been working on
> > enhancing the phoenix query server.
> >
> > Please join me in congratulating Karan.
> >
> > Thanks,
> > Thomas
> >
>
>
> --
> Best regards,
> Andrew
>
> Words like orphans lost among the crosstalk, meaning torn from truth's
> decrepit hands
>- A23, Crosstalk
>

Re: [ANNOUNCE] New Phoenix committer: Jaanai Zhang

[Vincent Poon]

Congrats, Jaanai !

On Mon, Dec 10, 2018 at 10:13 PM Geoffrey Jacoby  wrote:

> Congratulations, Jaanai!
>
> On Mon, Dec 10, 2018 at 2:05 PM Thomas D'Silva  wrote:
>
> > On behalf of the Apache Phoenix PMC, I am pleased to announce that Jaanai
> > Zhang has accepted our invitation to become a committer. He has found and
> > fixed several bugs [1]. He is also very active on the mailing list
> helping
> > out users and providing feedback on new features.
> >
> > We are looking forward to more great work.
> >
> > Thank you,
> > Thomas
> >
> > [1] *
> >
> https://issues.apache.org/jira/browse/PHOENIX-4974?jql=project%20%3D%20PHOENIX%20AND%20assignee%3Djaanai%20%20
> > <
> >
> https://issues.apache.org/jira/browse/PHOENIX-4974?jql=project%20%3D%20PHOENIX%20AND%20assignee%3Djaanai%20%20
> > >*
> >
>

Re: [ANNOUNCE] New Phoenix committer: Chinmay Kulkarni

[Vincent Poon]

Congrats, Chinmay!

On Mon, Dec 10, 2018 at 10:57 PM Karan Mehta  wrote:

> Congrats Chinmay!
> ᐧ
>
> On Mon, Dec 10, 2018 at 10:10 PM Geoffrey Jacoby 
> wrote:
>
> > Congratulations, Chinmay!
> >
> > Geoffrey Jacoby
> >
> > On Mon, Dec 10, 2018 at 1:45 PM Thomas D'Silva 
> wrote:
> >
> > > On behalf of the Apache Phoenix PMC, I am pleased to announce that
> > Chinmay
> > > Kulkarni has accepted our invitation to become a committer. Chinmay has
> > > contributed several metadata management improvements. He has also
> worked
> > on
> > > improving Phoenix code quality and fixed many bugs.
> > >
> > > Please welcome him to the Apache Phoenix team.
> > >
> > > Thank you,
> > > Thomas
> > >
> > > [1]
> > >
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20assignee%3Dckulkarni%20AND%20status%3DResolved
> > >
> >
>

[jira] [Updated] (PHOENIX-4832) Add Canary Test Tool for Phoenix Query Server

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4832:
--
Affects Version/s: 5.0.0
   4.14.1

> Add Canary Test Tool for Phoenix Query Server
> -
>
> Key: PHOENIX-4832
> URL: https://issues.apache.org/jira/browse/PHOENIX-4832
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Ashutosh Parekh
>Assignee: Swaroopa Kadam
>Priority: Minor
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-4832-4.x-HBase-1.4.patch, 
> PHOENIX-4832-4.x-HBase-1.4.patch, PHOENIX-4832-master.patch, 
> PHOENIX-4832.patch
>
>
> A suggested improvement is to add a Canary Test tool to the Phoenix Query 
> Server. It will execute a set of Basic Tests (CRUD) against a PQS end-point 
> and report on the proper functioning and testing results. A configurable Log 
> Sink can help to publish the results as required.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSS] Drop support for java 1.7 on the 1.2, 1.3 and 1.4 branches

[Vincent Poon]

+1 to another repo for connectors

On Mon, Dec 3, 2018 at 6:27 PM James Taylor  wrote:

> +1. Good idea, Thomas.
>
> On Mon, Dec 3, 2018 at 2:57 PM Thomas D'Silva 
> wrote:
>
> > I believe we will be maintaining the 4.x branches which support HBase
> 1.2,
> > 1.3 and 1.4 for a while.
> > Should we think about pulling out the connectors and queryserver into
> their
> > own repo similar to
> > what HBase did (see https://issues.apache.org/jira/browse/HBASE-20934).
> > They could then have
> > their own release schedule and Java support.
> >
> >
> > On Sat, Dec 1, 2018 at 6:53 AM Pedro Boado 
> wrote:
> >
> > > Well I don't count with a lot more 4.x releases - maybe I'm
> wrong-headed
> > .
> > > For master branch and cdh6 we'd be looking at spark 2.x
> > >
> > > Part of the success of a project is about version stability. Not a lot
> of
> > > corporate projects can afford keep upgrading to the latest versions -
> > think
> > > about it, you're in production, with a few thousand lines code running
> > > spark 1.6 ... And for upgrading to 4.14 you need to review all of this
> > > spark code -and maybe recompile to scala 2.11 btw- . It doesn't make
> > sense.
> > > Until now 4.x was pretty stable and in my opinion it should've never
> been
> > > migrated to spark 2 and java 8. Minor versions should keep certain
> > > stability in terms of dependencies.
> > >
> > > All these changes should've come with phoenix 5. But you're right it
> > needs
> > > a sensible solution as 4.14.1 is already out and compiled with java8.
> > >
> > >
> > >
> > > On Fri, 30 Nov 2018, 23:28 Thomas D'Silva  wrote:
> > >
> > > > Spark 1.6 is really old and doesn't support the newer Datasource v2
> api
> > > > that we have been looking at integrating with.
> > > > As Alex points out you will might end up having to revert a lot more
> > > > commits in the future.
> > > > Seems like the queryserver and phoenix-spark modules on the cdh
> branch
> > > > would end up diverging a lot from the standard open source branch.
> > > >
> > > >
> > > > On Fri, Nov 30, 2018 at 2:23 PM Alex Araujo 
> > > wrote:
> > > >
> > > > > > Only a downgrade to spark 1.6 (
> > > > > changes are only needed in a few IT, basically going back from
> > Datasets
> > > > to
> > > > > Dataframes)  and going back to Avatica 1.10 ( involving reverting
> > > > > PHOENIX-4755, PHOENIX-4750 and PHOENIX-4805 ).
> > > > >
> > > > > We're talking about the 4.x branches, right? Doesn't seem prudent
> to
> > do
> > > > it
> > > > > there as down-streamers may already be relying on the newer
> versions.
> > > > >
> > > > > On Fri, Nov 30, 2018 at 4:18 PM Pedro Boado  >
> > > > wrote:
> > > > >
> > > > > > Thinking about typical server installation in a corporate
> > environment
> > > > I'd
> > > > > > keep everything compatible with the same JVM version.
> > > > > >
> > > > > > I've gone down the route for the cdh branch. Full JDK 7
> > compatibility
> > > > > > doesn't require changes in phoenix-core. Only a downgrade to
> spark
> > > 1.6
> > > > (
> > > > > > changes are only needed in a few IT, basically going back from
> > > Datasets
> > > > > to
> > > > > > Dataframes)  and going back to Avatica 1.10 ( involving reverting
> > > > > > PHOENIX-4755, PHOENIX-4750 and PHOENIX-4805 ).
> > > > > >
> > > > > >
> > > > > > On Fri, 30 Nov 2018, 18:57 Thomas D'Silva  > > > > >  wrote:
> > > > > >
> > > > > > > We could allow individual submodules like the queryserver, or
> > > > > > phoenix-spark
> > > > > > > to be built with their own compiler configuration (1.8+).
> > > > > > > This would allow these modules to use Java 1.8 features. I
> think
> > > this
> > > > > > would
> > > > > > > be a good compromise given that they depend on
> > > > > > > features that are provided by versions of spark and avatica
> that
> > no
> > > > > > longer
> > > > > > > support Java 1.7.
> > > > > > > We can still ensure phoenix-core supports Java 1.7. You would
> > have
> > > to
> > > > > > skip
> > > > > > > building modules that require Java 1.8, WDYT?
> > > > > > >
> > > > > > > On Thu, Nov 29, 2018 at 6:11 PM Jaanai Zhang <
> > > cloud.pos...@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I'd vote for keep using java7 on 4.x branches. if upgrades to
> > > > java8,
> > > > > it
> > > > > > > > will impact users who want to upgrade the latest 4.x
> branches.
> > > they
> > > > > > must
> > > > > > > > consider using java8 in their running environments,  maybe
> > their
> > > > > > > libraries
> > > > > > > > do not support java8, then they have to give up to upgrade.
> So
> > I
> > > > > think
> > > > > > > that
> > > > > > > > drops support java7 is not friendly for some users.
> > > > > > > >
> > > > > > > >
> > > > > > > > 
> > > > > > > >Jaanai Zhang
> > > > > > > >Best regards!
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Pedro Boado  于2018年11月30日周五 上午6:13写道：
> > > > > > > >
> > > > > > > > > I'd vote for 

[jira] [Resolved] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-4781.
---
Resolution: Resolved

Pushed v5 to master and 4.x branches

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: 4.15.0, 5.1
>
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch, PHOENIX-4781.4.x-HBase-1.4.v4.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v5.patch, PHOENIX-4781.addendum.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: PHOENIX-4781.4.x-HBase-1.4.v5.patch

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: 4.15.0, 5.1
>
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch, PHOENIX-4781.4.x-HBase-1.4.v4.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v5.patch, PHOENIX-4781.addendum.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: PHOENIX-4781.4.x-HBase-1.4.v4.patch

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Fix For: 4.15.0, 5.1
>
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch, PHOENIX-4781.4.x-HBase-1.4.v4.patch, 
> PHOENIX-4781.addendum.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: PHOENIX-4781.addendum.patch

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch, PHOENIX-4781.addendum.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-1567) Publish Phoenix-Client & Phoenix-Server jars into Maven Repo

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-1567.
---
   Resolution: Fixed
Fix Version/s: 4.14.1

After applying PHOENIX-4781, I was able to publish the client and server jars 
for 4.14.1 here:
https://repository.apache.org/content/repositories/releases/org/apache/phoenix/phoenix-client/

Marking this resolved.

> Publish Phoenix-Client & Phoenix-Server jars into Maven Repo
> 
>
> Key: PHOENIX-1567
> URL: https://issues.apache.org/jira/browse/PHOENIX-1567
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.2.0
>Reporter: Jeffrey Zhong
>Assignee: Ankit Singhal
>Priority: Major
> Fix For: 4.14.1
>
> Attachments: PHOENIX-1567.patch
>
>
> Phoenix doesn't publish Phoenix Client & Server jars into Maven repository. 
> This make things quite hard for down steam projects/applications to use maven 
> to resolve dependencies.
> I tried to modify the pom.xml under phoenix-assembly while it shows the 
> following. 
> {noformat}
> [INFO] Installing 
> /Users/jzhong/work/phoenix_apache/checkins/phoenix/phoenix-assembly/target/phoenix-4.3.0-SNAPSHOT-client.jar
>  
> to 
> /Users/jzhong/.m2/repository/org/apache/phoenix/phoenix-assembly/4.3.0-SNAPSHOT/phoenix-assembly-4.3.0-SNAPSHOT-client.jar
> {noformat}
> Basically the jar published to maven repo will become  
> phoenix-assembly-4.3.0-SNAPSHOT-client.jar or 
> phoenix-assembly-4.3.0-SNAPSHOT-server.jar
> The artifact id "phoenix-assembly" has to be the prefix of the names of jars.
> Therefore, the possible solutions are:
> 1) rename current client & server jar to phoenix-assembly-clinet/server.jar 
> to match the jars published to maven repo.
> 2) rename phoenix-assembly to something more meaningful and rename our client 
> & server jars accordingly
> 3) split phoenix-assembly and move the corresponding artifacts into 
> phoenix-client & phoenix-server folders. Phoenix-assembly will only create 
> tar ball files.
> [~giacomotaylor], [~apurtell] or other maven experts: Any suggestion on this? 
> Thanks.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: PHOENIX-4781.4.x-HBase-1.4.v3.patch

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: (was: PHOENIX-4781.4.x-HBase-1.4.v3.patch)

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4781) Phoenix client project's jar naming convention causes maven-deploy-plugin to fail

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-4781:
--
Attachment: PHOENIX-4781.4.x-HBase-1.4.v3.patch

> Phoenix client project's jar naming convention causes maven-deploy-plugin to 
> fail
> -
>
> Key: PHOENIX-4781
> URL: https://issues.apache.org/jira/browse/PHOENIX-4781
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Karan Mehta
>Assignee: Karan Mehta
>Priority: Major
> Attachments: PHOENIX-4781.001.patch, PHOENIX-4781.002.patch, 
> PHOENIX-4781.4.x-HBase-1.4.v3.patch
>
>
> `maven-deploy-plugin` is used for deploying built artifacts to repository 
> provided by `distributionManagement` tag. The name of files that need to be 
> uploaded are either derived from pom file of the project or it generates an 
> temporary one on its own.
> For `phoenix-client` project, we essentially create a shaded uber jar that 
> contains all dependencies and provide the project pom file for the plugin to 
> work. `maven-jar-plugin` is disabled for the project, hence the shade plugin 
> essentially packages the jar. The final name of the shaded jar is defined as 
> `phoenix-${project.version}\-client`, which is different from how the 
> standard maven convention based on pom file (artifact and group id) is 
> `phoenix-client-${project.version}`
> This causes `maven-deploy-plugin` to fail since it is unable to find any 
> artifacts to be published.
> `maven-install-plugin` works correctly and hence it installs correct jar in 
> local repo.
> The same is effective for `phoenix-pig` project as well. However we require 
> the require jar for that project in the repo. I am not even sure why we 
> create shaded jar for that project.
> I will put up a 3 liner patch for the same.
> Any thoughts? [~sergey.soldatov] [~elserj]
> Files before change (first col is size):
> {code:java}
> 103487701 Jun 13 22:47 
> phoenix-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT-client.jar{code}
> Files after change (first col is size):
> {code:java}
> 3640 Jun 13 21:23 
> original-phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar
> 103487702 Jun 13 21:24 
> phoenix-client-4.14.0-HBase-1.3-sfdc-1.0.14-SNAPSHOT.jar{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-5050) Maven install of phoenix-client overwrites phoenix-core jar

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5050.
---
Resolution: Not A Problem

Was on an older branch, looks like this is fixed in PHOENIX-1567 , which is 
still unresolved.  Will see if I can finish any remaining work there.

> Maven install of phoenix-client overwrites phoenix-core jar
> ---
>
> Key: PHOENIX-5050
> URL: https://issues.apache.org/jira/browse/PHOENIX-5050
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>    Reporter: Vincent Poon
>Priority: Major
>
> If I run `mvn install -pl phoenix-client`, I get:
> I
> [INFO] --- maven-install-plugin:2.5.2:install-file (default-install) @ 
> phoenix-client ---
> [INFO] Installing 
> /Users/vincent.poon/git_public/apache_git_phoenix/phoenix-client/target/phoenix-4.13.1-HBase-1.3-client.jar
>  to 
> /Users/vincent.poon/.m2/repository/org/apache/phoenix/phoenix-core/4.13.1-HBase-1.3/phoenix-core-4.13.1-HBase-1.3.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5050) Maven install of phoenix-client overwrites phoenix-core jar

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5050:
-

 Summary: Maven install of phoenix-client overwrites phoenix-core 
jar
 Key: PHOENIX-5050
 URL: https://issues.apache.org/jira/browse/PHOENIX-5050
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.14.1, 5.0.0
Reporter: Vincent Poon


If I run `mvn install -pl phoenix-client`, I get:
I
[INFO] --- maven-install-plugin:2.5.2:install-file (default-install) @ 
phoenix-client ---
[INFO] Installing 
/Users/vincent.poon/git_public/apache_git_phoenix/phoenix-client/target/phoenix-4.13.1-HBase-1.3-client.jar
 to 
/Users/vincent.poon/.m2/repository/org/apache/phoenix/phoenix-core/4.13.1-HBase-1.3/phoenix-core-4.13.1-HBase-1.3.jar



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (PHOENIX-5048) Index Rebuilder does not handle INDEX_STATE timestamp check for all index

[Vincent Poon (JIRA)]

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

Vincent Poon reassigned PHOENIX-5048:
-

Assignee: Monani Mihir

> Index Rebuilder does not handle INDEX_STATE timestamp check for all index
> -
>
> Key: PHOENIX-5048
> URL: https://issues.apache.org/jira/browse/PHOENIX-5048
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.14.0, 4.14.1
>Reporter: Monani Mihir
>Assignee: Monani Mihir
>Priority: Major
> Attachments: PHOENIX-5048.patch
>
>
> After rebuilder is finished for Partial Index Rebuild, It will check if Index 
> state has been updated after Upper bound of the scan we use in partial index 
> Rebuild. If that happens then it will fail Index Rebuild as Index write 
> failure occured while we were rebuilding Index.
> {code:java}
> MetaDataEndpointImpl.java#updateIndexState()
> public void updateIndexState(RpcController controller, 
> UpdateIndexStateRequest request,
> RpcCallback done) {
> ...
> // If the index status has been updated after the upper bound of the scan we 
> use
> // to partially rebuild the index, then we need to fail the rebuild because an
> // index write failed before the rebuild was complete.
> if (actualTimestamp > expectedTimestamp) {
> builder.setReturnCode(MetaDataProtos.MutationCode.UNALLOWED_TABLE_MUTATION);
> builder.setMutationTime(EnvironmentEdgeManager.currentTimeMillis());
> done.run(builder.build());
> return;
> }
> ...
> }{code}
> After Introduction of TrackingParallelWriterIndexCommitter 
> [PHOENIX-3815|https://issues.apache.org/jira/browse/PHOENIX-3815], we only 
> disable Index which get failure . Before that , in 
> ParallelWriterIndexCommitter we were disabling all index even if Index 
> failure happens for one Index only. 
> Suppose Data Table has 3 index and above condition becomes true for first 
> index , then we won't even check for remain two Index.
> {code:java}
> MetaDataRegionObserver.java#BuildIndexScheduleTask.java#run()
> for (PTable indexPTable : indexesToPartiallyRebuild) {
> String indexTableFullName = SchemaUtil.getTableName(
> indexPTable.getSchemaName().getString(),
> indexPTable.getTableName().getString());
> if (scanEndTime == latestUpperBoundTimestamp) {
> IndexUtil.updateIndexState(conn, indexTableFullName, PIndexState.ACTIVE, 0L, 
> latestUpperBoundTimestamp);
> batchExecutedPerTableMap.remove(dataPTable.getName());
> LOG.info("Making Index:" + indexPTable.getTableName() + " active after 
> rebuilding");
> } else {
> // Increment timestamp so that client sees updated disable timestamp
> IndexUtil.updateIndexState(conn, indexTableFullName, 
> indexPTable.getIndexState(), scanEndTime * signOfDisableTimeStamp, 
> latestUpperBoundTimestamp);
> Long noOfBatches = batchExecutedPerTableMap.get(dataPTable.getName());
> if (noOfBatches == null) {
> noOfBatches = 0l;
> }
> batchExecutedPerTableMap.put(dataPTable.getName(), ++noOfBatches);
> LOG.info("During Round-robin build: Successfully updated index disabled 
> timestamp for "
> + indexTableFullName + " to " + scanEndTime);
> }
> }
> {code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-5046) Race condition in disabling an index can cause an index to get out of sync

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5046.
---
Resolution: Not A Problem

Nevermind, after looking more closely with [~tdsilva], the rowlock is happening 
correctly.

> Race condition in disabling an index can cause an index to get out of sync
> --
>
> Key: PHOENIX-5046
> URL: https://issues.apache.org/jira/browse/PHOENIX-5046
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>    Reporter: Vincent Poon
>Priority: Major
>
> Assume a row R at T0.
> If two index updates for R at T1 and T2 fail, the index might get marked 
> disabled as of T2 due to a race condition.  The partial rebuilder will will 
> then rebuild as of T2.  Since T1 was never replayed, the index row at T0 is 
> not deleted, leaving an extra orphan row in the index.
> This is because In MetaDataEndpointImpl#updateIndexState , we update the 
> index state without any rowlocking, so even though we take the min of the new 
> disable timestamp and the current disable timestamp, two concurrent requests 
> can be in a race condition and succeed in disabling the index with different 
> timestamps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5046) Race condition in disabling an index can cause an index to get out of sync

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5046:
-

 Summary: Race condition in disabling an index can cause an index 
to get out of sync
 Key: PHOENIX-5046
 URL: https://issues.apache.org/jira/browse/PHOENIX-5046
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.14.1, 5.0.0
Reporter: Vincent Poon


Assume a row R at T0.
If two index updates for R at T1 and T2 fail, the index might get marked 
disabled as of T2 due to a race condition.  The partial rebuilder will will 
then rebuild as of T2.  Since T1 was never replayed, the index row at T0 is not 
deleted, leaving an extra orphan row in the index.

This is because In MetaDataEndpointImpl#updateIndexState , we update the index 
state without any rowlocking, so even though we take the min of the new disable 
timestamp and the current disable timestamp, two concurrent requests can be in 
a race condition and succeed in disabling the index with different timestamps.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-5005) Server-side delete / upsert-select potentially blocked after a split

[Vincent Poon (JIRA)]

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

Vincent Poon resolved PHOENIX-5005.
---
   Resolution: Resolved
Fix Version/s: 4.15.0

Pushed to 4.x branches.  It seems the 5.x branch no longer has a preSplit hook, 
so not applying it there.

> Server-side delete / upsert-select potentially blocked after a split
> 
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Fix For: 4.15.0
>
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5005.4.x-HBase-1.4.v2.patch, PHOENIX-5005.4.x-HBase-1.4.v3.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to 
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy, 
> where a split is not retried.  For example, IncreasingToUpperBoundSplitPolicy 
> relies on the count of regions, and balancer movement of regions at t1 could 
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver 
> the flag to block inbound writes is flipped indefinitely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[ANNOUNCE] Apache Phoenix 4.14.1 released

[Vincent Poon]

The Apache Phoenix team is pleased to announce the immediate availability
of the 4.14.1 patch release. Apache Phoenix enables SQL-based OLTP and
operational analytics for Apache Hadoop using Apache HBase as its backing
store and providing integration with other projects in the Apache ecosystem
such as Spark, Hive, Pig, Flume, and MapReduce.

This patch release has feature parity with supported HBase versions and
includes critical bug fixes for secondary indexes.

Download source and binaries here [1].

Thanks,
Vincent (on behalf of the Apache Phoenix team)

[1] http://phoenix.apache.org/download.html

[jira] [Created] (PHOENIX-5019) Index mutations created by synchronous index builds will have wrong timestamps

[Vincent Poon (JIRA)]

Vincent Poon created PHOENIX-5019:
-

 Summary: Index mutations created by synchronous index builds will 
have wrong timestamps
 Key: PHOENIX-5019
 URL: https://issues.apache.org/jira/browse/PHOENIX-5019
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 5.0.0, 4.14.1
Reporter: Vincent Poon


Similar to PHOENIX-5018, if we do a synchronous index build, since it's doing 
an UpsertSelect , the timestamp of an index mutation will have current 
wallclock time instead matching up with the data table counterpart's timestamp



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5005) Server-side delete / upsert-select potentially blocked after a split

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5005:
--
Attachment: PHOENIX-5005.4.x-HBase-1.4.v3.patch

> Server-side delete / upsert-select potentially blocked after a split
> 
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5005.4.x-HBase-1.4.v2.patch, PHOENIX-5005.4.x-HBase-1.4.v3.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to 
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy, 
> where a split is not retried.  For example, IncreasingToUpperBoundSplitPolicy 
> relies on the count of regions, and balancer movement of regions at t1 could 
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver 
> the flag to block inbound writes is flipped indefinitely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5005) Server-side delete / upsert-select potentially blocked after a split

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5005:
--
Attachment: (was: PHOENIX-5005.4.x-HBase-1.4.v2.patch)

> Server-side delete / upsert-select potentially blocked after a split
> 
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5005.4.x-HBase-1.4.v2.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to 
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy, 
> where a split is not retried.  For example, IncreasingToUpperBoundSplitPolicy 
> relies on the count of regions, and balancer movement of regions at t1 could 
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver 
> the flag to block inbound writes is flipped indefinitely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5005) Server-side delete / upsert-select potentially blocked after a split

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5005:
--
Attachment: PHOENIX-5005.4.x-HBase-1.4.v2.patch

> Server-side delete / upsert-select potentially blocked after a split
> 
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5005.4.x-HBase-1.4.v2.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to 
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy, 
> where a split is not retried.  For example, IncreasingToUpperBoundSplitPolicy 
> relies on the count of regions, and balancer movement of regions at t1 could 
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver 
> the flag to block inbound writes is flipped indefinitely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5005) Server-side delete / upsert-select potentially blocked after a split

[Vincent Poon (JIRA)]

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

Vincent Poon updated PHOENIX-5005:
--
Attachment: PHOENIX-5005.4.x-HBase-1.4.v2.patch

> Server-side delete / upsert-select potentially blocked after a split
> 
>
> Key: PHOENIX-5005
> URL: https://issues.apache.org/jira/browse/PHOENIX-5005
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>    Reporter: Vincent Poon
>Assignee: Vincent Poon
>Priority: Major
> Attachments: PHOENIX-5005.4.x-HBase-1.4.v1.patch, 
> PHOENIX-5005.4.x-HBase-1.4.v2.patch
>
>
> After PHOENIX-4214, we stop inbound writes after a split is requested, to 
> avoid split starvation.
> However, it seems there can be edge cases, depending on the split policy, 
> where a split is not retried.  For example, IncreasingToUpperBoundSplitPolicy 
> relies on the count of regions, and balancer movement of regions at t1 could 
> make it such that the SplitPolicy triggers at t0 but not t2.
> However, after the first split request, in UngroupedAggregateRegionObserver 
> the flag to block inbound writes is flipped indefinitely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)