IndexToolForNonTxGlobalIndexIT.testIndexToolFailedMapperNotRecordToResultTable[mutable=true, singleCellIndex=true] almost failed on matser

2021-08-01 Thread cheng...@apache.org 
It seems that  
IndexToolForNonTxGlobalIndexIT.testIndexToolFailedMapperNotRecordToResultTable[mutable=true,
 singleCellIndex=true] almost failed on matser.
The stack is:
org.apache.phoenix.SystemExitRule$SystemExitInTestException
at 
org.apache.phoenix.TestSecurityManager.checkExit(TestSecurityManager.java:31)
at java.lang.Runtime.exit(Runtime.java:108)
at java.lang.System.exit(System.java:973)
at 
org.apache.phoenix.mapreduce.index.IndexTool.printHelpAndExit(IndexTool.java:454)
at 
org.apache.phoenix.mapreduce.index.IndexTool.printHelpAndExit(IndexTool.java:448)
at org.apache.phoenix.mapreduce.index.IndexTool.run(IndexTool.java:797)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:975)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:958)
at 
org.apache.phoenix.end2end.IndexToolForNonTxGlobalIndexIT.testIndexToolFailedMapperNotRecordToResultTable(IndexToolForNonTxGlobalIndexIT.java:655)
The error message is :
[main] org.apache.phoenix.end2end.IndexToolIT(974): Running IndexTool with 
[--schema=N17, --data-table=N18, --index-table=N19, -direct, -v, 
BEFORE, -runfg, -dl, NONE, -op, /tmp/93dd3660-6fc8-45f6-89c9-a704da477e18, -rv, 
1627707654873]
Can't do incremental index verification on this version of HBase because raw 
skip scan filters are not supported.

Re: IndexExtendedIT always failed on 4.x and master

2020-12-10 Thread cheng...@apache.org 



Yes， when I revert the 4.x before  PHOENIX-5140, the IndexExtendedIT and  
IndexScrutinyToolIT are sucess.
but after applying  PHOENIX-5140,both IndexExtendedIT and  IndexScrutinyToolIT 
are always failed.














At 2020-12-10 16:51:27, "Ankit Singhal"  wrote:
>Thanks Chenglei for bringing the failures to the notice. Have you confirmed
>that reverting PHOENIX-5140 fixes the problem? if yes then I would suggest
>reverting the fix and re-open the JIRA to be worked upon separately for the
>new fix.
>
>On Wed, Dec 9, 2020 at 7:14 PM cheng...@apache.org 
>wrote:
>
>> I noticed IndexExtendedIT always failed on 4.x and master now, It may be
>> caused by PHOENIX-5140 , for 4.x , the stack is :
>> java.lang.AssertionError: expected:<0> but was:<-1>
>> at org.junit.Assert.fail(Assert.java:89)
>> at org.junit.Assert.failNotEquals(Assert.java:835)
>> at org.junit.Assert.assertEquals(Assert.java:647)
>> at org.junit.Assert.assertEquals(Assert.java:633)
>> at
>> org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:806)
>> at
>> org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:785)
>> at
>> org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:776)
>> at
>> org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:770)
>> at
>> org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:744)
>> at
>> org.apache.phoenix.end2end.IndexExtendedIT.testMutableIndexWithUpdates(IndexExtendedIT.java:166)
>>
>>
>> and the similar stack is on master， I suggest we should rollback or stop
>> commit to the repo until the problem is fixed.

IndexExtendedIT always failed on 4.x and master

2020-12-09 Thread cheng...@apache.org 
I noticed IndexExtendedIT always failed on 4.x and master now, It may be caused 
by PHOENIX-5140 , for 4.x , the stack is :
java.lang.AssertionError: expected:<0> but was:<-1>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:633)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:806)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:785)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:776)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:770)
at 
org.apache.phoenix.end2end.IndexToolIT.runIndexTool(IndexToolIT.java:744)
at 
org.apache.phoenix.end2end.IndexExtendedIT.testMutableIndexWithUpdates(IndexExtendedIT.java:166)


and the similar stack is on master， I suggest we should rollback or stop commit 
to the repo until the problem is fixed.

Re:[Discuss] Releasing Phoenix 4.16

2020-12-01 Thread cheng...@apache.org 



In my opinion, we should  keep releases light and frequent, and for some 
unusual query bugs like RVC and DESC
we could delay fix to next release . I think we should release 4.16.0 and 5.1.0 
as quickly as possible. In China, many users 
in HBase&Phoenix User Group thought that  Phoenix was dead because our too long 
interval release and stopped using
Phoenix. 














At 2020-12-02 08:45:46, "Chinmay Kulkarni"  wrote:
>I agree. These are all major bugs and we should aim at solving them after
>checking that they are still issues. I am +1 on 5833 and I think 5484 would
>be a great addition to 4.16 as well. We should aim at resolving high
>priority bugs like this in every release.
>
>Sometimes we let these bugs slip without a resolution before a release,
>citing that these are "known issues" or "not regressions from the last
>release". In some cases this may be fine since we want to keep releases
>light and frequent, but perhaps we can track such issues and aim at
>reducing the number of bugs by x% in each release? This will also keep old
>Jiras alive since we will potentially periodically review them.
>
>
>On Tue, Dec 1, 2020 at 4:01 PM Geoffrey Jacoby  wrote:
>
>> I've got PHOENIX-5435 in review right now, and would like to get it in 4.16
>> / 5.1.
>>
>> It's allowing the annotation of Phoenix metadata into HBase WALs as a
>> pre-req for the Phoenix Change Detection Capture framework (PHOENIX-5442).
>> Since it has both client/server logic, and adds a field to System.Catalog,
>> it can't go in a patch release.
>>
>> Depending on timing, I'd _like_ to get PHOENIX-6227, which is the last part
>> of CDC that will go into core Phoenix, into 4.16, but since that _can_ go
>> in a patch release and I haven't started it yet, if the release gets cut
>> before it's ready, no big deal. (The rest of CDC will go into
>> phoenix-connectors for a future release of that project.)
>>
>> As for the correctness problems that Daniel points out, I think we should
>> fix the ones that were detected with a recent version (4.14 or 4.15?), and
>> test to see which of the older ones can still be reproduced. Once we know
>> which bugs are real and which are just historical, we can better judge
>> scope. And hopefully close a bunch of obsolete bugs. (Thanks, Daniel, for
>> collecting that list!)
>>
>> Geoffrey
>>
>>
>>
>> On Tue, Dec 1, 2020 at 1:33 PM Daniel Wong
>>  wrote:
>>
>> > Hi, I wanted to bring up wrong results in Phoenix and some JIRAs around
>> > them that I think we should fix as the wrong result lessens the end
>> user's
>> > trust in Phoenix.  Releasing a new version without addressing these in a
>> > minor release hurts our visibility in that these critical issues are not
>> > addressed.
>> >
>> > Jira's that I'm involved with for example: I've already given a patch
>> > several months ago for 5833 and there is a chance it may fix 5484.
>> >   https://issues.apache.org/jira/browse/PHOENIX-5833
>> >   https://issues.apache.org/jira/browse/PHOENIX-5484
>> >
>> > In addition, inspecting apache JIRA i see several other wrong result
>> JIRAs
>> > from the community.  Some of these certainly are probably old issues or
>> > incorrect understanding but some of these are opened by our own dev
>> > community and are likely real problems.
>> >   https://issues.apache.org/jira/browse/PHOENIX-6217
>> >   https://issues.apache.org/jira/browse/PHOENIX-5571
>> >   https://issues.apache.org/jira/browse/PHOENIX-4642
>> >   https://issues.apache.org/jira/browse/PHOENIX-4540
>> >   https://issues.apache.org/jira/browse/PHOENIX-4504
>> >   https://issues.apache.org/jira/browse/PHOENIX-4419
>> >   https://issues.apache.org/jira/browse/PHOENIX-4116
>> >
>> > What is our stance on this type of issue?  Are we going to say these were
>> > issues prior to 4.15 and not address them?  Should we have requirements
>> for
>> > our releases to fix wrong results?
>> >
>> > Daniel Wong
>> >
>> > On Mon, Nov 30, 2020 at 7:30 PM Xinyi Yan  wrote:
>> >
>> > > Hi all,
>> > >
>> > > It's time to discuss the Phoenix 4.16 release. After many people's
>> > > contributions on the bug fixes, new features, and other works in the
>> past
>> > > few months, we are kind of close to the point to have a RC (still need
>> to
>> > > fix test flappers). Please let me know if you think any JIRA must be
>> part
>> > > of the Phoenix 4.16 release other than major blocker PHOENIX-5712.
>> > >
>> > > If no surprise comes up, I will not wait for any new major features and
>> > > focus on the RC as soon as possible.
>> > >
>> > > Sincerely,
>> > > Xinyi
>> > >
>> >
>> >
>> > --
>> > Daniel Wong
>> > Salesforce
>> > Mobile: 628.217.1808
>> >
>>
>
>
>-- 
>Chinmay Kulkarni

Re: [DISCUSS] moving 4.x to phoenix-thirdparty Guava

2020-11-24 Thread cheng...@apache.org 



I hope that we should applying PHOENIX-6010 to the 4.x, which could simplify 
back- and forward porting changes between the branches,or else for many 
JIRAs,we should




prepare separated patches for 4.x and master.











At 2020-11-25 00:52:26, "Geoffrey Jacoby"  wrote:
>Istvan,
>
>Harmonizing the uses of guava between the two branches makes a lot of
>sense. The current differences add to the merge conflicts when porting a
>significant change between the branches, and make it easy to mistakenly use
>an unshaded version of guava in the master branch (as I accidentally did
>once. :-) )
>
>The main question I see is when to do it -- before the upcoming 4.16
>release or afterward for a 4.16.1 or 4.17? That depends on release timing.
>
>Geoffrey
>
>On Tue, Nov 24, 2020 at 7:07 AM Istvan Toth  wrote:
>
>> Hi!
>>
>> I'd like to gather your opinion on replacing Guava with the
>> phoenix-thirdparty shaded version on the 4.x branch.
>>
>> The change was not applied on 4.x, as the incompatibilities that the
>> pre-shaded Guava version solves are not present on Hadoop 2/Hbase 1.
>> However, the difference between the branches causes extra work, and
>> frequent problems when porting code between the branches.
>> Applying PHOENIX-6010 to the 4.x branch would make our lives easier, while
>> having no negative effects that I know of (we already pull in
>> phoenix-thirdparty via Omid 1.0.2)
>>
>> looking forward to hearing your opinion
>> Istvan
>>

4.x branch Compile Error When hbase.profile >=1.4

2020-11-23 Thread cheng...@apache.org 
When Compile 4.x with hbase.profile >=1.4, there is following compile error, It 
may be caused by PHOENIX-6155:




phoenix-core/src/test/java/org/apache/phoenix/coprocessor/TaskMetaDataEndpointTest.java:[73,52]
  is not 
abstract and does not override abstract method 
getMetricRegistryForRegionServer() in 
org.apache.hadoop.hbase.coprocessor.RegionCoprocessorEnvironment

Re: No builds on Phoenix-Master jenkins since Feb 19th?

2020-06-21 Thread cheng...@apache.org 












I observed that when the ITtests hange,  the ZK connection exhaustion is caused 
by ViewUtil.dropChildViews , and I opened a JIRA PHOENIX-5970 to solve it, 
seems that it works.





At 2020-06-19 14:58:27, "Istvan Toth"  wrote:
>The hanging test suite issue has been fixed by Richard Antal's PHOENIX-5962
> .
>Tests should be back to normal (that is, they're still flakey as fresh snow)
>
>Rajeshbabu, is there an easy way (specific message in the logs) for
>identifying the ZK connection exhaustion situation?
>
>Istvan
>
>On Thu, Jun 18, 2020 at 2:49 AM rajeshb...@apache.org <
>chrajeshbab...@gmail.com> wrote:
>
>> Just my observation related tests hang or flaky ness is that when there are
>> connections created which involves zookeeper connection then at some point
>> of time zookeeper sees too many connections and not allow to create further
>> connections then the cluster won't be terminated immediately and tests
>> hangs. We can identify such cases and close the connections properly if
>> any.
>>
>> Thanks,
>> Rajeshbabu.
>>
>> On Tue, Jun 16, 2020, 12:12 PM Istvan Toth  wrote:
>>
>> > What we really need is getting our test suite (and infra) sorted out.
>> > Your suggestions are already part of the process, it's just that lately
>> > everyone ignores them, because the precommit tests have been next to
>> > useless for a good while.
>> >
>> > I think that if developers can be reasonably sure that the precommit
>> > failure that they see is not some kind of random/known flake, they (we)
>> > will take them seriously, and not commit until they(we) get it right.
>> >
>> > Blocking further commits until the tests are fixed is one drastic, but
>> > possibly necessary measure to achieve this.
>> > And once we get them fixed, we will indeed need to be more vigilant in
>> not
>> > letting the situation deteriorate.
>> >
>> > Istvan
>> >
>> > On Mon, Jun 15, 2020 at 7:30 PM Andrew Purtell 
>> > wrote:
>> >
>> > > So it's time to enforce an automatic revert if build fails policy?
>> > > Ideally, no commit before a precommit passes.
>> > > If that fails, if someone discovers failing tests and can git bisect to
>> > the
>> > > cause, automatic revert of the offending commit.
>> > >
>> > > YDYT?
>> > >
>> > >
>> > > On Sun, Jun 14, 2020 at 10:20 PM Istvan Toth
>> > > >
>> > > wrote:
>> > >
>> > > > Unfortunately you are not missing anything, Lars :(
>> > > >
>> > > > What's worse, the tests are not only failing, they even hang since
>> Jun
>> > 2.
>> > > > Master is in a similar state.
>> > > >
>> > > > regards
>> > > > Istvan
>> > > >
>> > > > On Sun, Jun 14, 2020 at 12:03 AM la...@apache.org 
>> > > > wrote:
>> > > >
>> > > > > Thanks Istvan.
>> > > > >
>> > > > > Just checked the builds. Looks like the 4.x builds have not passed
>> a
>> > > > > single time since May 20th.
>> > > > >
>> > > > > I hope I am missing something... Otherwise this would be pretty
>> > > > > frustrating. :)
>> > > > > (Since pleading doesn't appear to help, maybe we should
>> automatically
>> > > > > block all commits until all tests pass...?)
>> > > > >
>> > > > > -- Lars
>> > > > >
>> > > > >
>> > > > > On Tuesday, April 21, 2020, 5:33:52 AM PDT, Istvan Toth <
>> > > > st...@apache.org>
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > I've deleted all but the four Phoenix jobs listed in the JIRA.
>> > > > >
>> > > > >
>> > > >
>> > > > --
>> > > > *István Tóth* | Staff Software Engineer
>> > > > st...@cloudera.com 
>> > > > [image: Cloudera] 
>> > > > [image: Cloudera on Twitter]  [image:
>> > > > Cloudera on Facebook]  [image:
>> > > Cloudera
>> > > > on LinkedIn] 
>> > > > 
>> > > > --
>> > > >
>> > >
>> > >
>> > > --
>> > > Best regards,
>> > > Andrew
>> > >
>> > > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > > decrepit hands
>> > >- A23, Crosstalk
>> > >
>> >
>>

Re:Re: Master branch does not compile

2020-06-17 Thread cheng...@apache.org 



Should we only support HBase 2.2 , which is a stable 2.x release ?  














At 2020-06-17 16:04:58, "Istvan Toth"  wrote:
>The 4.x branch has historically deprecated unsupported branches.
>
>I'd be fine with removing support for EOL 2.x branches in master,
>https://issues.apache.org/jira/browse/PHOENIX-5716 is open for this very
>issue,
>but would welcome some community input before working on it.
>
>I also like Josh's idea, https://issues.apache.org/jira/browse/PHOENIX-5828 is
>quite similar to it.
>
>
>On Wed, Jun 17, 2020 at 2:49 AM Guanghao Zhang  wrote:
>
>> HBase 2.0 and 2.1 has been EOL now. Does phoenix need to support them?
>>
>> swaroopa kadam  于2020年6月17日周三 上午12:32写道：
>>
>> > yes, that’s a good idea.
>> >
>> > On Tue, Jun 16, 2020 at 9:29 AM Josh Elser  wrote:
>> >
>> > > Sounds like we should try to update precommit to at least compile
>> > > against _a version_ in each line 2.1/2.2/2.3 for master. Thoughts?
>> > >
>> > > On 6/16/20 11:57 AM, swaroopa kadam wrote:
>> > > > Thank you for the replies everyone!
>> > > >
>> > > > It puts me at ease by knowing the issue has been identified and being
>> > > > fixed.
>> > > >
>> > > > Thanks!
>> > > >
>> > > > On Tue, Jun 16, 2020 at 4:11 AM rajeshb...@apache.org <
>> > > > chrajeshbab...@gmail.com> wrote:
>> > > >
>> > > >> I am on the PHOENIX-5905 compilation issue and will fix it today.
>> > > >>
>> > > >> On Tue, Jun 16, 2020 at 3:07 PM cheng...@apache.org <
>> > > cheng...@apache.org>
>> > > >> wrote:
>> > > >>
>> > > >>>
>> > > >>>
>> > > >>>
>> > > >>> PHOENIX-5905 caused the master branch compile broken, because
>> > > >>> org.apache.hadoop.hbase.security.access.GetUserPermissionsRequest
>> is
>> > > only
>> > > >>> available in hbase 2.2.x,
>> > > >>> so when the hbase.profile=2.0 or  hbase.profile=2.1, the compiler
>> > > boken,
>> > > >>> Should we revert PHOENIX-5905 for the moment?
>> > > >>>
>> > > >>>
>> > > >>> The error messages are :
>> > > >>>
>> > > >>>
>> > > >>> [ERROR] COMPILATION ERROR :
>> > > >>> [INFO]
>> -
>> > > >>> [ERROR] <
>> > > >>>
>> > > >>
>> > >
>> >
>> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>> > > >>> :[39,47]
>> > > >>> cannot find symbol
>> > > >>>symbol:   class GetUserPermissionsRequest
>> > > >>>location: package org.apache.hadoop.hbase.security.access
>> > > >>> [ERROR] <
>> > > >>>
>> > > >>
>> > >
>> >
>> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>> > > >>> :[1452,48]
>> > > >>> cannot find symbol
>> > > >>>symbol:   method hasUserName()
>> > > >>>location: variable request of type
>> > > >>>
>> > > >>
>> > >
>> >
>> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
>> > > >>> [ERROR] <
>> > > >>>
>> > > >>
>> > >
>> >
>> https://builds.apache.org/job/Phoenix-master-matrix/HBASE_PROFILE=2.1/ws/phoenix-core/src/it/java/org/apache/phoenix/end2end/BasePermissionsIT.java
>> > > >>> :[1452,72]
>> > > >>> cannot find symbol
>> > > >>>symbol:   method getUserName()
>> > > >>>location: variable request of type
>> > > >>>
>> > > >>
>> > >
>> >
>> org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
>> > > >>> [ERROR] <
>> > > >>>
>> > > >>
>> > >
>>

PHOENIX-5905 caused the master branch compile broken for a few days

2020-06-16 Thread cheng...@apache.org 
PHOENIX-5905 caused the master branch compile broken, because 
org.apache.hadoop.hbase.security.access.GetUserPermissionsRequest is only 
available in hbase 2.2.x, 
so when the hbase.profile=2.0 or  hbase.profile=2.1, the compiler boken,
Should we revert PHOENIX-5905 for the moment?


The error messages are :


[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[39,47]
 cannot find symbol
  symbol:   class GetUserPermissionsRequest
  location: package org.apache.hadoop.hbase.security.access
[ERROR] 
:[1452,48]
 cannot find symbol
  symbol:   method hasUserName()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1452,72]
 cannot find symbol
  symbol:   method getUserName()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1458,32]
 cannot find symbol
  symbol:   method hasColumnFamily()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1458,60]
 cannot find symbol
  symbol:   method getColumnFamily()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1460,32]
 cannot find symbol
  symbol:   method hasColumnQualifier()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1460,63]
 cannot find symbol
  symbol:   method getColumnQualifier()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1461,17]
 cannot find symbol
  symbol:   class GetUserPermissionsRequest
  location: class 
org.apache.phoenix.end2end.BasePermissionsIT.CustomAccessController
[ERROR] 
:[1463,49]
 cannot find symbol
  symbol:   variable GetUserPermissionsRequest
  location: class 
org.apache.phoenix.end2end.BasePermissionsIT.CustomAccessController
[ERROR] 
:[1467,29]
 cannot find symbol
  symbol:   variable GetUserPermissionsRequest
  location: class org.apache.phoenix.end2end.BasePermissionsIT.Custo

Re:Re: Master branch does not compile

2020-06-16 Thread cheng...@apache.org 



PHOENIX-5905 caused the master branch compile broken, because 
org.apache.hadoop.hbase.security.access.GetUserPermissionsRequest is only 
available in hbase 2.2.x, 
so when the hbase.profile=2.0 or  hbase.profile=2.1, the compiler boken,
Should we revert PHOENIX-5905 for the moment?


The error messages are :


[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
:[39,47]
 cannot find symbol
  symbol:   class GetUserPermissionsRequest
  location: package org.apache.hadoop.hbase.security.access
[ERROR] 
:[1452,48]
 cannot find symbol
  symbol:   method hasUserName()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1452,72]
 cannot find symbol
  symbol:   method getUserName()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1458,32]
 cannot find symbol
  symbol:   method hasColumnFamily()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1458,60]
 cannot find symbol
  symbol:   method getColumnFamily()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1460,32]
 cannot find symbol
  symbol:   method hasColumnQualifier()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1460,63]
 cannot find symbol
  symbol:   method getColumnQualifier()
  location: variable request of type 
org.apache.hadoop.hbase.protobuf.generated.AccessControlProtos.GetUserPermissionsRequest
[ERROR] 
:[1461,17]
 cannot find symbol
  symbol:   class GetUserPermissionsRequest
  location: class 
org.apache.phoenix.end2end.BasePermissionsIT.CustomAccessController
[ERROR] 
:[1463,49]
 cannot find symbol
  symbol:   variable GetUserPermissionsRequest
  location: class 
org.apache.phoenix.end2end.BasePermissionsIT.CustomAccessController
[ERROR] 
:[1467,29]
 cannot find symbol
  symbol:   variable GetUserPermissionsRequest
  location: class org.apache.phoenix.end2end.BasePermissionsIT.Custo


















At 2020-06-16 14:26:23, "Istvan Toth"  wrote:
>Hi!
>
>In some cases specifying non-default HBase and Hadoop versions can cause
>this.
>Please report your full maven command line, and I'll look into it.
>In the meantime you can disable the dependency check with -D
>mdep.analyze.skip=true
>
>Istvan
>
>On Mon, Jun 15, 2020 at 7:57 PM swaroopa kadam 
>wrote:
>
>> Thank you for the response, Andrew and Geoffrey. Below is the error message
>> I see:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-dependency-plugin:3.1.1:analyze-only
>> (enforce-dependencies) on project phoenix-core: Dependency problems found
>> -> [Help 1]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
>> switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
>> [ERROR]
>> [ERROR] After correcting the problems, you can resume the build with the
>> command
>> [ERROR]   mvn  -rf :phoenix-core
>>
>>
>> On Mon, Jun 15, 2020 at 10:4

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

2019-10-30 Thread cheng...@apache.org 
+1








At 2019-10-31 07:57:32, "rajeshb...@apache.org"  
wrote:
>+1
>
>On Wed, Oct 30, 2019, 11:55 PM Ankit Singhal 
>wrote:
>
>> +1
>>
>> On Wed, Oct 30, 2019 at 10:44 AM Andrew Purtell 
>> wrote:
>>
>> > +0 (binding)
>> >
>> > I support this but it isn't my time I'd be committing to maintaining the
>> > new repos with a +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
>> > >
>> >
>> >
>> > --
>> > Best regards,
>> > Andrew
>> >
>> > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > decrepit hands
>> >- A23, Crosstalk
>> >
>>

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

2019-08-26 Thread cheng...@apache.org 



Congratulations and welcome, Chinmay!






At 2019-08-27 07:00:29, "Ankit Singhal"  wrote:
>Congratulations Chinmay !!
>
>On Mon, Aug 26, 2019 at 1:33 PM Thomas D'Silva  wrote:
>
>> Congrats Chinmay, well deserved!
>>
>> On Mon, Aug 26, 2019 at 11:00 AM Vincent Poon 
>> wrote:
>>
>> > 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:Re: [VOTE] Release of Apache Phoenix 4.14.3 RC2

2019-08-19 Thread cheng...@apache.org 
@gjacoby, Thank you very much for the explaination,


When I untar the apache-phoenix-4.14.3-HBase-1.4-src.tar.gz using tar (GNU tar) 
1.23 under Red Hat Enterprise Linux Server release 6.6, I got following 
warnings for
every subdirectory:
tar: Ignoring unknown extended header keyword `SCHILY.dev'
tar: Ignoring unknown extended header keyword `SCHILY.ino'
tar: Ignoring unknown extended header keyword `SCHILY.nlink'


When I untared the same src tar.gz using WinRAR 3.7.0 under windows 7, I got 
"PaxHeader" directory in every subdirectory.

Furthermore, when I untar apache-phoenix-4.14.2-HBase-1.4-src.tar.gz  or other 
earlier versions in the same environment, I did not see the warnings or the 
"PaxHeader" directory.





At 2019-08-20 07:24:53, "Geoffrey Jacoby"  wrote:
>Oops, forgot to add the footnote above: [1]
>https://www.gnu.org/software/tar/manual/html_chapter/tar_8.html#SEC146
>
>On Mon, Aug 19, 2019 at 4:23 PM Geoffrey Jacoby  wrote:
>
>> Looking at this some more, I created Docker containers for CentOS and
>> Ubuntu and verified that I could use the GNU version of tar they included
>> to successfully untar the tarball in the RC. (There were some extraneous
>> warnings -- apparently BSD tar uses a few headers that GNU tar doesn't
>> understand -- but they didn't affect the output.)
>>
>> The GNU docs specify that the POSIX extensions to the tar format is
>> supported in 1.14 or later[1], and recent CentOS and Ubuntu releases have
>> included tar versions far later than that, such as 1.26 in CentOS.
>>
>> So far RC2 still seems OK to me, but very curious to know what the
>> environment is where it's failing. Once we know that we can judge how
>> serious it is. Worst case, we can do an RC3 using GNU tar to make the
>> tarballs.
>>
>> Geoffrey
>>
>> On Mon, Aug 19, 2019 at 9:45 AM Geoffrey Jacoby 
>> wrote:
>>
>>> Cheng is a PMC member and has a binding vote. Just as a reminder, the
>>> Apache policy for releases is at least 3 +1s and more positive votes than
>>> negative; releases can't be vetoed the way patches can.[1] That said, we've
>>> always taken -1s very seriously, and I agree that if the tarball is corrupt
>>> that would be a reason for sinking the RC.
>>>
>>> Like Swaroopa, I can't reproduce the problem. I've untarred the source on
>>> several different machines over the past week or so and not seen the
>>> PaxHeaders that Cheng is seeing. It may be relevant that all the machines
>>> I've done this on have been Macs, which use the BSD tar.
>>>
>>> Some searching shows that PaxHeaders are apparently a POSIX extension to
>>> the tarball standard [2] and that a tar utility that doesn't understand the
>>> extension may manifest the extra headers as extra files.
>>>
>>> Cheng, could you please share what version of tar or other decompression
>>> tool you're using to help us figure this out?
>>>
>>> Geoffrey
>>> [1] http://www.apache.org/legal/release-policy.html#release-approval
>>> [2] https://stackoverflow.com/questions/34688392/paxheaders-in-tarball
>>>
>>> On Mon, Aug 19, 2019 at 9:00 AM swaroopa kadam <
>>> swaroopa.kada...@gmail.com> wrote:
>>>
>>>> Thank you all who voted.
>>>>
>>>> cheng...@apache.org - I downloaded and untarred the tar files on Linux,
>>>> macOS, and windows. I didn't see the "PaxHeader" in any environment.
>>>> Is your -1 binding or non-binding?
>>>>
>>>> Thank you.
>>>>
>>>> On Mon, Aug 19, 2019 at 7:48 AM cheng...@apache.org >>> >
>>>> wrote:
>>>>
>>>> >
>>>> > -1,
>>>> > I am very strange to find that there is a "PaxHeader" directory in
>>>> every
>>>> > subdirectory in the
>>>> >
>>>> >
>>>> >
>>>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc2/src/apache-phoenix-4.14.3-HBase-1.3-src.tar.gz
>>>> > and
>>>> >
>>>> >
>>>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc2/src/apache-phoenix-4.14.3-HBase-1.4-src.tar.gz
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > At 2019-08-15 01:24:16, "swaroopa kadam" 
>>>> > wrote:
>>>> >

Re:[VOTE] Release of Apache Phoenix 4.14.3 RC2

2019-08-19 Thread cheng...@apache.org 

-1, 
I am very strange to find that there is a "PaxHeader" directory in every 
subdirectory in the

https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc2/src/apache-phoenix-4.14.3-HBase-1.3-src.tar.gz
 and
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc2/src/apache-phoenix-4.14.3-HBase-1.4-src.tar.gz







At 2019-08-15 01:24:16, "swaroopa kadam"  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&version=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
>

Re: [ANNOUNCE] Kadir Ozdemir is a new Phoenix Committer

2019-06-04 Thread cheng...@apache.org 


Congratulations and welcome, Kadir!






At 2019-06-04 04:11:59, "Chinmay Kulkarni"  wrote:
>Congratulations Kadir!
>
>On Mon, Jun 3, 2019 at 12:26 PM Priyank Porwal 
>wrote:
>
>> Congrats Kadir!
>>
>> > On Jun 3, 2019, at 11:35 AM, Andrew Purtell  wrote:
>> >
>> > Congratulations and welcome, Kadir!
>> >
>> >> On Mon, Jun 3, 2019 at 9:57 AM Geoffrey Jacoby 
>> wrote:
>> >>
>> >> On behalf of the Apace Phoenix PMC, I am pleased to announce that Kadir
>> >> Ozdemir has accepted our invitation to become a Phoenix committer. Kadir
>> >> has already made a significant impact on the project, including major
>> >> improvements to the index rebuild tool, an orphaned view cleanup tool,
>> and
>> >> landing very soon, a major revamp of mutable secondary indexes to make
>> them
>> >> self-repairing.
>> >>
>> >> Congratulations, Kadir, and looking forward to more great contributions!
>> >>
>> >> Geoffrey Jacoby
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> > Andrew
>> >
>> > Words like orphans lost among the crosstalk, meaning torn from truth's
>> > decrepit hands
>> >   - A23, Crosstalk
>>
>
>
>-- 
>Chinmay Kulkarni
>M.S. Computer Science,
>University of Illinois at Urbana-Champaign.
>B. Tech Computer Engineering,
>College of Engineering, Pune.

PHOENIX-5181 causes compile error for branch 4.x-HBase-1.3 and 4.x-HBase-1.4

2019-05-21 Thread cheng...@apache.org 
For branch 4.x-HBase-1.3 and 4.x-HBase-1.4,  the package name of 
"org.apache.phoenix.expression.function.MathTrigFunctionTest.java"   is 
"org.apache.phoenix.expression", which causes compile failed.
This class is introduced by PHOENIX-5181,  @yanxinyi,  Could you please fix it ?

Re: [VOTE] Release of Apache Phoenix 4.14.2 RC1

2019-05-20 Thread cheng...@apache.org 
+1, verified in my Environment.








At 2019-05-20 09:16:37, "Jaanai Zhang"  wrote:
>+1
>
>
>   Jaanai Zhang
>   Best regards!
>
>
>
>Thomas D'Silva  于2019年5月18日周六 下午3:38写道：
>
>> Hello Everyone,
>>
>> This is a call for a vote on Apache Phoenix 4.14.2 RC1. 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-rc1/src/
>>
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/src/
>>
>> The binary artifacts can be found at:
>>
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc1/bin/
>>
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/bin/
>>
>> For a complete list of changes, see:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120&version=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=e3505d91e46de1a1756a145d396f27a3c70e927f
>>
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=4b717825fb284c1f9fbdeee3d0e5391f5baf13bb
>>
>>
>> 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
>>

Re: [ANNOUNCE] New Phoenix committer: Mihir Monani

2019-04-30 Thread cheng...@apache.org 
Congratulations and welcome Mihir!







在 2019-04-30 14:35:54，"Jaanai Zhang"  写道：
>congrats! Mihir.
>
>
>   Jaanai Zhang
>   Best regards!
>
>
>
>Mihir Monani  于2019年4月30日周二 下午1:13写道：
>
>> Thanks Thomas and Apache Phoenix Community. :)
>>
>> On Sun, Apr 28, 2019 at 6:12 AM Thomas D'Silva  wrote:
>>
>> > On behalf of the Apache Phoenix PMC, I am pleased to announce that
>> > Mihir Monani has accepted our invitation to become a committer.
>> > Mihir has done some nice work fixing several bugs related to indexing[1].
>> >
>> > Please welcome him to the Apache Phoenix team.
>> >
>> > Thanks,
>> > Thomas
>> >
>> > [1]
>> >
>> >
>> https://issues.apache.org/jira/browse/PHOENIX-5199?jql=project%20%3D%20PHOENIX%20AND%20assignee%3D%22mihir6692%22%20AND%20status%3DResolved
>> >
>>
>>
>> --
>> Mihir Monani
>> (+91)-9429473434
>>

Re:Re: [DISCUSS] Making a 4.14.2 release for bug fixes

2019-04-16 Thread cheng...@apache.org 



willshen, I think bugfix PHOENIX-5217 could be inclueded. 





At 2019-04-17 01:28:43, "William Shen"  wrote:
>Bump, anyone else would like to chime in regarding what should or should
>not be included as part of 4.14.2?
>
>Right now we have, based on the filter:
>Issue Type Issue key Summary Status Resolution
>Bug PHOENIX-5243 PhoenixResultSet#next() closes the result set if scanner
>returns null Patch Available
>Bug PHOENIX-5207 Create index if not exists fails incorrectly if table has
>'maxIndexesPerTable' indexes already  Resolved Fixed
>Bug PHOENIX-5184 HBase and Phoenix connection leaks in Indexing code path,
>OrphanViewTool and PhoenixConfigurationUtil Resolved Fixed
>Bug PHOENIX-5169 Query logger is still initialized for each query when the
>log level is off Resolved Fixed
>Improvement PHOENIX-5131 Make spilling to disk for order/group by
>configurable Resolved Fixed
>Bug PHOENIX-5126 RegionScanner leak leading to store files not getting
>cleared Resolved Fixed
>Bug PHOENIX-5123 Avoid using MappedByteBuffers for server side GROUP BY
>Resolved Fixed
>Bug PHOENIX-5122 PHOENIX-4322 breaks client backward compatibility Resolved
>Fixed
>Bug PHOENIX-5101 ScanningResultIterator getScanMetrics throws NPE Resolved
>Fixed
>Bug PHOENIX-5084 Changes from Transactional Tables are not visible to query
>in different client Resolved Fixed
>Bug PHOENIX-5073 Invalid PIndexState during rolling upgrade from 4.13 to
>4.14 Resolved Fixed
>Improvement PHOENIX-5069 Use asynchronous refresh to provide non-blocking
>Phoenix Stats Client Cache Resolved Fixed
>Improvement PHOENIX-5026 Add client setting to disable server side mutations
>Resolved Fixed
>Improvement PHOENIX-4900 Modify MAX_MUTATION_SIZE_EXCEEDED and
>MAX_MUTATION_SIZE_BYTES_EXCEEDED exception message to recommend turning
>autocommit on for deletes Resolved Fixed
>
>On Sat, Apr 13, 2019 at 5:59 PM William Shen 
>wrote:
>
>> Also, there're a handful of tickets already marked with Fix Version 4.14.2:
>>
>> https://issues.apache.org/jira/browse/PHOENIX-5207?jql=project%20%3D%20PHOENIX%20AND%20fixVersion%20%3D%204.14.2
>>
>> On Fri, Apr 12, 2019 at 3:09 PM Chinmay Kulkarni <
>> chinmayskulka...@gmail.com> wrote:
>>
>>> +1 to the idea of a 4.14.2 release. Here are some JIRAs to backport that
>>> come to mind:
>>>
>>> https://issues.apache.org/jira/browse/PHOENIX-5184
>>> https://issues.apache.org/jira/browse/PHOENIX-5169
>>> https://issues.apache.org/jira/browse/PHOENIX-5131
>>>
>>> Thanks,
>>> Chinmay
>>>
>>>
>>> On Fri, Apr 12, 2019 at 1:33 PM William Shen 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Since there're still some blockers for 4.15, what does the community
>>> feel
>>> > about back-porting some of the bug fixes for a 4.14.2 release?
>>> >
>>> > One issue I have in mind is the NPE fix (
>>> > https://issues.apache.org/jira/browse/PHOENIX-5101). Is there anything
>>> > else
>>> > that would be of interest?
>>> >
>>> > Thanks
>>> >
>>> > - Will
>>> >
>>>
>>>
>>> --
>>> Chinmay Kulkarni
>>> M.S. Computer Science,
>>> University of Illinois at Urbana-Champaign.
>>> B. Tech Computer Engineering,
>>> College of Engineering, Pune.
>>>
>>

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

2019-04-10 Thread cheng...@apache.org 


Congratulations Geoffrey!


At 2019-04-10 09:34:53, "Jaanai Zhang"  wrote:
>Congratulations Geoffrey!
>
>
>   Jaanai Zhang
>   Best regards!
>
>
>
>Abhishek Singh Chouhan  于2019年4月10日周三
>上午4:50写道：
>
>> Congrats Geoffrey!!
>>
>> On Tue, Apr 9, 2019 at 12:00 PM Chinmay Kulkarni <
>> chinmayskulka...@gmail.com>
>> wrote:
>>
>> > Congratulations Geoffrey!
>> >
>> > On Tue, Apr 9, 2019 at 11:51 AM Vincent Poon 
>> > wrote:
>> >
>> > > 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
>> > > >
>> > >
>> >
>> >
>> > --
>> > Chinmay Kulkarni
>> > M.S. Computer Science,
>> > University of Illinois at Urbana-Champaign.
>> > B. Tech Computer Engineering,
>> > College of Engineering, Pune.
>> >
>>