[jira] [Updated] (PHOENIX-1394) getColumnDisplaySize() method returns incorrect value for varchar columns
[ https://issues.apache.org/jira/browse/PHOENIX-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Lob updated PHOENIX-1394: Description: The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20. getColumnDisplaySize() method returns incorrect value for varchar columns - Key: PHOENIX-1394 URL: https://issues.apache.org/jira/browse/PHOENIX-1394 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: windows 7 Reporter: Sergio Lob The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-1394) getColumnDisplaySize() method returns incorrect value for varchar columns
Sergio Lob created PHOENIX-1394: --- Summary: getColumnDisplaySize() method returns incorrect value for varchar columns Key: PHOENIX-1394 URL: https://issues.apache.org/jira/browse/PHOENIX-1394 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: windows 7 Reporter: Sergio Lob -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1394) getColumnDisplaySize() method returns incorrect value for varchar columns
[ https://issues.apache.org/jira/browse/PHOENIX-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Lob updated PHOENIX-1394: Description: The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20. This contrasts with a char(20) column, for which getColumnDisplaySize() returns the correct value of 20. (was: The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20.) getColumnDisplaySize() method returns incorrect value for varchar columns - Key: PHOENIX-1394 URL: https://issues.apache.org/jira/browse/PHOENIX-1394 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: windows 7 Reporter: Sergio Lob The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20. This contrasts with a char(20) column, for which getColumnDisplaySize() returns the correct value of 20. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1387) Local index is not use when the query like select * from dataTable where c1 like 'abc%'.
[ https://issues.apache.org/jira/browse/PHOENIX-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] rajeshbabu updated PHOENIX-1387: Attachment: PHOENIX-1387.patch [~jamestaylor] Here is the patch. Please review. Local index is not use when the query like select * from dataTable where c1 like 'abc%'. -- Key: PHOENIX-1387 URL: https://issues.apache.org/jira/browse/PHOENIX-1387 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: jdk1.6 linux Reporter: jelly Chen Assignee: rajeshbabu Attachments: PHOENIX-1387.patch According to the official doc: Local indexes can be used even when the query isn't fully covered i.e. Phoenix automatically retrieve the columns not in the index through point gets against the data table. But the index did not be used when i executed query statement like select * from dataTable where c1 like 'abc%'. Certainly 'c1' is indexed in local index. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-1394) getColumnDisplaySize() method returns incorrect value for varchar columns
[ https://issues.apache.org/jira/browse/PHOENIX-1394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-1394: -- Assignee: Samarth Jain getColumnDisplaySize() method returns incorrect value for varchar columns - Key: PHOENIX-1394 URL: https://issues.apache.org/jira/browse/PHOENIX-1394 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: windows 7 Reporter: Sergio Lob Assignee: Samarth Jain The ResultSetMetaData.getColumnDisplaySize() method returns incorrect value for varchar columns. For example: for a varchar(20) column, getColumnDisplaySize() incorrectly returns value of 10 instead of 20. This contrasts with a char(20) column, for which getColumnDisplaySize() returns the correct value of 20. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1387) Local index is not use when the query like select * from dataTable where c1 like 'abc%'.
[ https://issues.apache.org/jira/browse/PHOENIX-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14188536#comment-14188536 ] James Taylor commented on PHOENIX-1387: --- +1 on the patch, [~rajesh23]. Thanks for the quick turnaround. [~jelly] - work around is to explicitly list out all of the columns instead of using * (until this patch makes it into a release). Local index is not use when the query like select * from dataTable where c1 like 'abc%'. -- Key: PHOENIX-1387 URL: https://issues.apache.org/jira/browse/PHOENIX-1387 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: jdk1.6 linux Reporter: jelly Chen Assignee: rajeshbabu Attachments: PHOENIX-1387.patch According to the official doc: Local indexes can be used even when the query isn't fully covered i.e. Phoenix automatically retrieve the columns not in the index through point gets against the data table. But the index did not be used when i executed query statement like select * from dataTable where c1 like 'abc%'. Certainly 'c1' is indexed in local index. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PHOENIX-1378) (state=42M03,code=1012) happened when create index
[ https://issues.apache.org/jira/browse/PHOENIX-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alicia Ying Shu reassigned PHOENIX-1378: Assignee: Alicia Ying Shu (state=42M03,code=1012) happened when create index -- Key: PHOENIX-1378 URL: https://issues.apache.org/jira/browse/PHOENIX-1378 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Reporter: xufeng Assignee: Alicia Ying Shu 1. create a table 2.put 1200 rows into the table. 3.create index on the table by [create index customer_name_index on T_BLACK_LIST(CUSTOMER_NAME) include(DATA_BUILDTIME,DATA_SOURCE,BLACKLIST_TYPE,MONEY_BOUND,DATE_CREATED,CREATED_BY,DATE_UPDATED,UPDATED_BY) salt_buckets=9;] 4.after 30 minute: Error: ERROR 1012 (42M03): Table undefined. tableName=CUSTOMER_NAME_INDEX (state=42M03,code=1012) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
RE: [VOTE] Release of Apache Phoenix 4.2.0 RC1
+1 on the RC1. Downloaded the src tarball, built it and ran all the testcases from it. Stats part looks fine to me. Regards Ram -Original Message- From: Eli Levine [mailto:elilev...@gmail.com] Sent: Thursday, October 30, 2014 1:53 AM To: dev@phoenix.apache.org Subject: Re: [VOTE] Release of Apache Phoenix 4.2.0 RC1 +1 Ran though the same set of tests as I did for RC0. Looks good to me. No issues found. Go Phoenix! Thanks, Eli On Tue, Oct 28, 2014 at 4:50 PM, James Taylor jamestay...@apache.org wrote: Hi everyone, This is a call for a vote on Apache Phoenix 4.2.0 RC1. This is the next minor release of Phoenix compatible with the 0.98 branch of Apache HBase with feature parity against the upcoming Phoenix 3.2.0 release. The release includes both a source-only release and a convenience binary release. In addition to 50+ bug fixes, the following new features were added: - Statistics collection to improve query performance[1] - Semi/anti joins (IN and EXISTS subqueries) - Correlated subqueries (with some restrictions) - Optimized parent/child join execution - Annotated connection properties included in tracing and logging - Local immutable indexes to decrease network IO - Delete support for tables with immutable rows - New operators and built-ins: ILIKE (case insensitive LIKE), REGEXP_SPLIT For a complete list of changes, see: https://raw.githubusercontent.com/apache/phoenix/4.0/CHANGES The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.0-rc1/src/ The binary artifacts can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.0-rc1/bin/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/mujtaba.asc KEYS file available here: https://dist.apache.org/repos/dist/release/phoenix/KEYS The hash and tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=5614d bd5eb196cd13ee8c8ea75ee7927cd6644a3 https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tag s/v4.2.0-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 [1] http://phoenix.apache.org/update_statistics.html
[jira] [Commented] (PHOENIX-1387) Local index is not use when the query like select * from dataTable where c1 like 'abc%'.
[ https://issues.apache.org/jira/browse/PHOENIX-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14189500#comment-14189500 ] jelly Chen commented on PHOENIX-1387: - [~jamestaylor], [~rajesh23] Ok, Thanks for your support! Local index is not use when the query like select * from dataTable where c1 like 'abc%'. -- Key: PHOENIX-1387 URL: https://issues.apache.org/jira/browse/PHOENIX-1387 Project: Phoenix Issue Type: Bug Affects Versions: 4.1 Environment: jdk1.6 linux Reporter: jelly Chen Assignee: rajeshbabu Attachments: PHOENIX-1387.patch According to the official doc: Local indexes can be used even when the query isn't fully covered i.e. Phoenix automatically retrieve the columns not in the index through point gets against the data table. But the index did not be used when i executed query statement like select * from dataTable where c1 like 'abc%'. Certainly 'c1' is indexed in local index. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-1215) some phoenix transactions are hanging indefinitely on ps.execute() call
[
https://issues.apache.org/jira/browse/PHOENIX-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma resolved PHOENIX-1215.
Resolution: Invalid
This turned out to be a issue in our client implementation. Closing.
some phoenix transactions are hanging indefinitely on ps.execute() call
---
Key: PHOENIX-1215
URL: https://issues.apache.org/jira/browse/PHOENIX-1215
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.0.0
Environment: Num Cores: 24, Model : Intel(R) Xeon(R) CPU E5-2420 0 @
1.90GHz
MemTotal: 65801264 kB, 1 Gbps Network
Red Hat Enterprise Linux Server release 6.2
Reporter: Vikas Vishwakarma
Test Setup:
==
4 load client with 16 threads each running against a HBase cluster with 6
RegionServers.
Each load client spawns a thread and runs a upsert query in batch mode
Pseudo code:
==
SQL_UPSERT_HBASE_DATA = UPSERT INTO TABLE_NAME (ROW_KEY_ID, ROW_VAL) VALUES
(?, ?)
for (int i=0; i6400; i++) {
upsertSql.append(SQL_UPSERT_HBASE_DATA);
ps = conn.prepareStatement(preparedSqlTableStmt.toString());
ps.setString(1, rowKey);
ps.setString(2, rowVal);
ps.execute();
}
conn.commit();
tryClose(conn);
Observation:
==
Observing some issues where a small number of transactions (approx 40 out of
80,000) are hanging indefinitely on preparedStatement.execute() call.
I tried to put a timeout on the transaction but looks like phoenix still does
not support preparedStatement.setQueryTimeout().
Log Analysis:
=
On the client side there are no errors or exceptions except some threads in
hung state
On the service side, the observation is as follows:
Also after some log analysis, it looks like all the batches that got stuck,
are during the start of the test. From the RegionServer logs, the phoenix
co-processor loading and index updates is in progress during this time (which
involves some failures and retries). Once this phase is over, remaining write
batches that started later have succeeded.
RegionServer log snapshots during the time period this issue was observed on
the client side:
-
2014-08-27 03:28:00,114 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ScanRegionObserver from HTD of
HT_42 successfully.
2014-08-27 03:28:00,114 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ScanRegionObserver from HTD of
HT_42 successfully.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,931 INFO
org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver: Starting
ungrouped coprocessor scan
{timeRange:[0,1409110080691],batch:-1,startRow:\\x0E,stopRow:\\x0F,loadColumnFamiliesOnDemand:true,totalColumns:1,cacheBlocks:true,families:{0:[ALL]},maxResultSize:-1,maxVersions:1,caching:-1}
2014-08-27 03:28:00,931 INFO
org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver: Starting
ungrouped coprocessor scan
{timeRange:[0,1409110080691],batch:-1,startRow:\\x07,stopRow:\\x08,loadColumnFamiliesOnDemand:true,totalColumns:1,cacheBlocks:true,families:{0:[ALL]},maxResultSize:-1,maxVersions:1,caching:-1}
2014-08-27 03:28:06,507 DEBUG
org.apache.hadoop.hbase.coprocessor.CoprocessorHost: Loading coprocessor
class org.apache.phoenix.coprocessor.ServerCachingEndpointImpl with path null
and priority 1
2014-08-27 03:28:06,507 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ServerCachingEndpointImpl from HTD
of HT_44 successfully.
2014-08-27 03:28:06,508 DEBUG
org.apache.hadoop.hbase.coprocessor.CoprocessorHost: Loading coprocessor
class org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver with path
null and priority 1
2014-08-27 03:28:06,508 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver
from HTD of HT_44 successfully.
...
2014-08-27 03:28:19,525 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to
[jira] [Closed] (PHOENIX-1215) some phoenix transactions are hanging indefinitely on ps.execute() call
[
https://issues.apache.org/jira/browse/PHOENIX-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Vishwakarma closed PHOENIX-1215.
--
This turned out to be a issue in our client implementation. Closing.
some phoenix transactions are hanging indefinitely on ps.execute() call
---
Key: PHOENIX-1215
URL: https://issues.apache.org/jira/browse/PHOENIX-1215
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.0.0
Environment: Num Cores: 24, Model : Intel(R) Xeon(R) CPU E5-2420 0 @
1.90GHz
MemTotal: 65801264 kB, 1 Gbps Network
Red Hat Enterprise Linux Server release 6.2
Reporter: Vikas Vishwakarma
Test Setup:
==
4 load client with 16 threads each running against a HBase cluster with 6
RegionServers.
Each load client spawns a thread and runs a upsert query in batch mode
Pseudo code:
==
SQL_UPSERT_HBASE_DATA = UPSERT INTO TABLE_NAME (ROW_KEY_ID, ROW_VAL) VALUES
(?, ?)
for (int i=0; i6400; i++) {
upsertSql.append(SQL_UPSERT_HBASE_DATA);
ps = conn.prepareStatement(preparedSqlTableStmt.toString());
ps.setString(1, rowKey);
ps.setString(2, rowVal);
ps.execute();
}
conn.commit();
tryClose(conn);
Observation:
==
Observing some issues where a small number of transactions (approx 40 out of
80,000) are hanging indefinitely on preparedStatement.execute() call.
I tried to put a timeout on the transaction but looks like phoenix still does
not support preparedStatement.setQueryTimeout().
Log Analysis:
=
On the client side there are no errors or exceptions except some threads in
hung state
On the service side, the observation is as follows:
Also after some log analysis, it looks like all the batches that got stuck,
are during the start of the test. From the RegionServer logs, the phoenix
co-processor loading and index updates is in progress during this time (which
involves some failures and retries). Once this phase is over, remaining write
batches that started later have succeeded.
RegionServer log snapshots during the time period this issue was observed on
the client side:
-
2014-08-27 03:28:00,114 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ScanRegionObserver from HTD of
HT_42 successfully.
2014-08-27 03:28:00,114 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ScanRegionObserver from HTD of
HT_42 successfully.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,252 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27 03:28:00,931 INFO
org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver: Starting
ungrouped coprocessor scan
{timeRange:[0,1409110080691],batch:-1,startRow:\\x0E,stopRow:\\x0F,loadColumnFamiliesOnDemand:true,totalColumns:1,cacheBlocks:true,families:{0:[ALL]},maxResultSize:-1,maxVersions:1,caching:-1}
2014-08-27 03:28:00,931 INFO
org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver: Starting
ungrouped coprocessor scan
{timeRange:[0,1409110080691],batch:-1,startRow:\\x07,stopRow:\\x08,loadColumnFamiliesOnDemand:true,totalColumns:1,cacheBlocks:true,families:{0:[ALL]},maxResultSize:-1,maxVersions:1,caching:-1}
2014-08-27 03:28:06,507 DEBUG
org.apache.hadoop.hbase.coprocessor.CoprocessorHost: Loading coprocessor
class org.apache.phoenix.coprocessor.ServerCachingEndpointImpl with path null
and priority 1
2014-08-27 03:28:06,507 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.ServerCachingEndpointImpl from HTD
of HT_44 successfully.
2014-08-27 03:28:06,508 DEBUG
org.apache.hadoop.hbase.coprocessor.CoprocessorHost: Loading coprocessor
class org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver with path
null and priority 1
2014-08-27 03:28:06,508 INFO
org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost: Loaded
coprocessor org.apache.phoenix.coprocessor.GroupedAggregateRegionObserver
from HTD of HT_44 successfully.
...
2014-08-27 03:28:19,525 INFO org.apache.phoenix.hbase.index.Indexer: Found
some outstanding index updates that didn't succeed during WAL replay -
attempting to replay now.
2014-08-27
Re: [VOTE] Release of Apache Phoenix 3.2.0 RC1
+1 Ran test suite based on source tar ball. Cheers On Tue, Oct 28, 2014 at 4:49 PM, James Taylor jamestay...@apache.org wrote: Hi everyone, This is a call for a vote on Apache Phoenix 3.2.0 RC1. This is the next minor release of Phoenix compatible with the 0.94 branch of Apache HBase with feature parity against the upcoming Phoenix 4.2.0 release. The release includes both a source-only release and a convenience binary release. In addition to 50+ bug fixes, the following new features were added: - Statistics collection to improve query performance[1] - Semi/anti joins (IN and EXISTS subqueries) - Correlated subqueries (with some restrictions) - Optimized parent/child join execution - Delete support for tables with immutable rows - New operators and built-ins: ILIKE (case insensitive LIKE), REGEXP_SPLIT For a complete list of changes, see: https://raw.githubusercontent.com/apache/phoenix/3.0/CHANGES The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-3.2.0-rc1/src/ The binary artifacts can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-3.2.0-rc1/bin/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/mujtaba.asc KEYS file available here: https://dist.apache.org/repos/dist/release/phoenix/KEYS The hash and tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=8b460b5c086f46b3e636133df90932c80c1a643a https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tags/v3.2.0-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 [1] http://phoenix.apache.org/update_statistics.html
Re: [VOTE] Release of Apache Phoenix 4.2.0 RC1
+1 on the RC1. I¹ve downloaded the bin tar-ball setup on 0.98.4-hadoop2. All following steps run smoothly. 1) Use sqlline create drop a table 2) use psql creates a table, load data query data 3) run ./bin/performance.py localhost 2 On 10/29/14, 6:16 PM, Vasudevan, Ramkrishna S ramkrishna.s.vasude...@intel.com wrote: +1 on the RC1. Downloaded the src tarball, built it and ran all the testcases from it. Stats part looks fine to me. Regards Ram -Original Message- From: Eli Levine [mailto:elilev...@gmail.com] Sent: Thursday, October 30, 2014 1:53 AM To: dev@phoenix.apache.org Subject: Re: [VOTE] Release of Apache Phoenix 4.2.0 RC1 +1 Ran though the same set of tests as I did for RC0. Looks good to me. No issues found. Go Phoenix! Thanks, Eli On Tue, Oct 28, 2014 at 4:50 PM, James Taylor jamestay...@apache.org wrote: Hi everyone, This is a call for a vote on Apache Phoenix 4.2.0 RC1. This is the next minor release of Phoenix compatible with the 0.98 branch of Apache HBase with feature parity against the upcoming Phoenix 3.2.0 release. The release includes both a source-only release and a convenience binary release. In addition to 50+ bug fixes, the following new features were added: - Statistics collection to improve query performance[1] - Semi/anti joins (IN and EXISTS subqueries) - Correlated subqueries (with some restrictions) - Optimized parent/child join execution - Annotated connection properties included in tracing and logging - Local immutable indexes to decrease network IO - Delete support for tables with immutable rows - New operators and built-ins: ILIKE (case insensitive LIKE), REGEXP_SPLIT For a complete list of changes, see: https://raw.githubusercontent.com/apache/phoenix/4.0/CHANGES The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.0-rc1/src/ The binary artifacts can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-4.2.0-rc1/bin/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/mujtaba.asc KEYS file available here: https://dist.apache.org/repos/dist/release/phoenix/KEYS The hash and tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=5614d bd5eb196cd13ee8c8ea75ee7927cd6644a3 https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tag s/v4.2.0-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 [1] http://phoenix.apache.org/update_statistics.html -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
RE: [VOTE] Release of Apache Phoenix 3.2.0 RC1
+1. Downloaded the tar ball. Compiled the src and ran the test cases. Regards Ram -Original Message- From: Ted Yu [mailto:yuzhih...@gmail.com] Sent: Thursday, October 30, 2014 9:59 AM To: dev@phoenix.apache.org Subject: Re: [VOTE] Release of Apache Phoenix 3.2.0 RC1 +1 Ran test suite based on source tar ball. Cheers On Tue, Oct 28, 2014 at 4:49 PM, James Taylor jamestay...@apache.org wrote: Hi everyone, This is a call for a vote on Apache Phoenix 3.2.0 RC1. This is the next minor release of Phoenix compatible with the 0.94 branch of Apache HBase with feature parity against the upcoming Phoenix 4.2.0 release. The release includes both a source-only release and a convenience binary release. In addition to 50+ bug fixes, the following new features were added: - Statistics collection to improve query performance[1] - Semi/anti joins (IN and EXISTS subqueries) - Correlated subqueries (with some restrictions) - Optimized parent/child join execution - Delete support for tables with immutable rows - New operators and built-ins: ILIKE (case insensitive LIKE), REGEXP_SPLIT For a complete list of changes, see: https://raw.githubusercontent.com/apache/phoenix/3.0/CHANGES The source tarball, including signatures, digests, etc can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-3.2.0-rc1/src/ The binary artifacts can be found at: https://dist.apache.org/repos/dist/dev/phoenix/phoenix-3.2.0-rc1/bin/ Release artifacts are signed with the following key: https://people.apache.org/keys/committer/mujtaba.asc KEYS file available here: https://dist.apache.org/repos/dist/release/phoenix/KEYS The hash and tag to be voted upon: https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=8b460 b5c086f46b3e636133df90932c80c1a643a https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=tag;h=refs/tag s/v3.2.0-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 [1] http://phoenix.apache.org/update_statistics.html
