[jira] [Commented] (PHOENIX-2063) Row value constructor doesn't work when used in COUNT DISTINCT
[
https://issues.apache.org/jira/browse/PHOENIX-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618100#comment-14618100
]
James Taylor commented on PHOENIX-2063:
---
Maybe we need to add a call to reset() in ServerAggregators here like this? Or
is this happening on the client side?
{code}
@Override
public void aggregate(Aggregator[] aggregators, Tuple result) {
for (int i = 0; i < expressions.length; i++) {
if (expressions[i].evaluate(result, ptr) && ptr.getLength() != 0) {
aggregators[i].aggregate(result, ptr);
}
expressions[i].reset();
}
}
{code}
If server-side, would you mind trying this to see if it helps?
> Row value constructor doesn't work when used in COUNT DISTINCT
> --
>
> Key: PHOENIX-2063
> URL: https://issues.apache.org/jira/browse/PHOENIX-2063
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Dumindu Buddhika
> Attachments: PHOENIX-2063-v1.patch
>
>
> As a workaround for PHOENIX-2062, I tried the following query:
> {code}
> SELECT COUNT(DISTINCT (a.col1, b.col2)) ...
> {code}
> However, this always returns 1 as the COUNT DISTINCT which is wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618092#comment-14618092
]
James Taylor commented on PHOENIX-2074:
---
Thanks for the info, [~ram_krish]. I think her patch is checked in - would you
mind running with the latest to see if the issue goes away?
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618086#comment-14618086
]
ramkrishna.s.vasudevan commented on PHOENIX-2074:
-
[~giacomotaylor]
I just happened to see this issue and just wanted to show a case where I could
produce this StackOverFlow. Am not sure if this is related to this issue.
{code}
java.lang.StackOverflowError
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
at
org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
{code}
I can just create this by running a query like this
{code}
SELECT HOST FROM PERFORMANCE_4500;
{code}
I think [~maryannxue]'s point is right.
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618059#comment-14618059 ] Hudson commented on PHOENIX-2025: - FAILURE: Integrated in Phoenix-master #817 (See [https://builds.apache.org/job/Phoenix-master/817/]) PHOENIX-2025 - Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps (Thomas D'Silva) (ravimagham: rev 973bccb7019bfb0c15a9fd5259d7b01f37859b52) * phoenix-core/src/main/java/org/apache/phoenix/mapreduce/util/PhoenixConfigurationUtil.java * phoenix-core/src/main/java/org/apache/phoenix/mapreduce/util/ConnectionUtil.java > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025-optional-client-port.patch, > PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2058) Check for existence and compatibility of columns being added in view
[ https://issues.apache.org/jira/browse/PHOENIX-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14618040#comment-14618040 ] James Taylor commented on PHOENIX-2058: --- Thanks, [~tdsilva], +1, but would you mind including the test you removed, but with an Ignore tag and comment about why? I think we'll want to enable it if PHOENIX-978 gets fixed. > Check for existence and compatibility of columns being added in view > > > Key: PHOENIX-2058 > URL: https://issues.apache.org/jira/browse/PHOENIX-2058 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Thomas D'Silva > Attachments: PHOENIX-2058-WIP.patch, PHOENIX-2058.patch, > PHOENIX-2058.v2.patch, PHOENIX-2058.wip.2.patch > > > One check I realized we're not doing, but need to do, is ensuring that the > column being added by the base table doesn't already exist in the view. If > the column does already exist, ideally we can allow the addition to the base > table if the type matches and the scale is null or >= existing scale and the > maxLength is null or >= existing maxLength. Also, if a column is a PK column > and it already exists in the view, the position in the PK must match. > The fact that we've materialized a PTable for the view should make the > addition of this check easier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617996#comment-14617996 ] maghamravikiran commented on PHOENIX-2025: -- [~tdsilva] Pushed your patch to all the branches. Thanks . > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025-optional-client-port.patch, > PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617952#comment-14617952 ] James Taylor commented on PHOENIX-2025: --- Actually, Thomas' patch is fine as-is, as he's depending on the return of null from getClientPort to indicate that there's no client port specified. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025-optional-client-port.patch, > PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[
https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617945#comment-14617945
]
James Taylor commented on PHOENIX-2025:
---
[~tdsilva] is right - we need to look for the client port in the URL first and
then fall back to the config. Can we combine the two patches, though and still
do this in getClientPort():
{code}
configuration.getInt(HBASE_ZOOKEEPER_CLIENT_PORT,HConstants.DEFAULT_ZOOKEPER_CLIENT_PORT);
{code}
instead of this:
{code}
String clientPortString =
configuration.get(HBASE_ZOOKEEPER_CLIENT_PORT);
return clientPortString==null ? null :
Integer.parseInt(clientPortString);
{code}
> Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting
> up in client apps
> -
>
> Key: PHOENIX-2025
> URL: https://issues.apache.org/jira/browse/PHOENIX-2025
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.3.0
>Reporter: Geoffrey Jacoby
>Assignee: Geoffrey Jacoby
> Fix For: 5.0.0, 4.5.0, 4.4.1
>
> Attachments: PHOENIX-2025-ClientPortIssue.patch,
> PHOENIX-2025-default-zkport, PHOENIX-2025-optional-client-port.patch,
> PHOENIX-2025.patch, PHOENIX-2025_v2.patch
>
>
> Phoenix seems to have long had its own version of hbase-default.xml as a test
> resource in phoenix-core with a single setting to override
> hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3,
> phoenix-core seems to have been split into a main jar and a test jar, and the
> hbase-default.xml went into the test jar.
> The odd result of this is that in client apps that include the test jar, the
> classloader in HBaseConfiguration.create() now sees Phoenix's
> hbase-default.xml, rather than HBase's, and creates a Configuration object
> without HBase's defaults. One major consequence of this is that the
> HBaseTestingUtility can't start up, because it relies on those HBase defaults
> being set. This is a huge problem in a client app that includes the
> phoenix-core test jar in order to make use of the PhoenixTestDriver and
> BaseTest classes; the upgrade to 4.3 breaks all tests using the
> HBaseTestingUtility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2058) Check for existence and compatibility of columns being added in view
[ https://issues.apache.org/jira/browse/PHOENIX-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-2058: Attachment: PHOENIX-2058.v2.patch [~jamestaylor] I have attached a patch with the est removed. > Check for existence and compatibility of columns being added in view > > > Key: PHOENIX-2058 > URL: https://issues.apache.org/jira/browse/PHOENIX-2058 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Thomas D'Silva > Attachments: PHOENIX-2058-WIP.patch, PHOENIX-2058.patch, > PHOENIX-2058.v2.patch, PHOENIX-2058.wip.2.patch > > > One check I realized we're not doing, but need to do, is ensuring that the > column being added by the base table doesn't already exist in the view. If > the column does already exist, ideally we can allow the addition to the base > table if the type matches and the scale is null or >= existing scale and the > maxLength is null or >= existing maxLength. Also, if a column is a PK column > and it already exists in the view, the position in the PK must match. > The fact that we've materialized a PTable for the view should make the > addition of this check easier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated PHOENIX-2025: Attachment: PHOENIX-2025-optional-client-port.patch [~maghamraviki...@gmail.com] IndexToolIT passes for me. Using the default zookeeper port in getClientPort(), still doesn't help with the PhoenixConfigurationUtilTest test failures. I tried only using the client port in the url if it is not null and after that PhoenixConfigurationUtilTest passes. I attached a patch. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025-optional-client-port.patch, > PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617921#comment-14617921 ] maghamravikiran commented on PHOENIX-2025: -- [~tdsilva] I will work on the tests and push a patch . Also, does IndexToolIT test succeed in your local environment ? > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617916#comment-14617916 ] James Taylor commented on PHOENIX-2025: --- +1, [~maghamraviki...@gmail.com]. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617901#comment-14617901 ] Thomas D'Silva commented on PHOENIX-2025: - PhoenixConfigurationUtilTest seems to be failing after checking in Mujtaba's patch. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maghamravikiran updated PHOENIX-2025: - Attachment: PHOENIX-2025-default-zkport Minor change to return default zk port in PhoenixConfigurationUtil. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, > PHOENIX-2025-default-zkport, PHOENIX-2025.patch, PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-978) Allow views to extend base table's PK
[ https://issues.apache.org/jira/browse/PHOENIX-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617847#comment-14617847 ] James Taylor commented on PHOENIX-978: -- [~elilevine] - there' an issue that [~tdsilva] discovered with allowing a view to extend the base table's PK: https://issues.apache.org/jira/browse/PHOENIX-2058?focusedCommentId=14617813&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14617813 It'll cause those rows to no longer be readable by the base table. This JIRA will require more work - basically we'd need to no longer assume that we can treat the remaining bytes in a row key as the value of the last column. This is an optimization we do to prevent walking the row key to look for our separator byte (for var length types only). > Allow views to extend base table's PK > - > > Key: PHOENIX-978 > URL: https://issues.apache.org/jira/browse/PHOENIX-978 > Project: Phoenix > Issue Type: Sub-task >Affects Versions: 3.0.0, 4.0.0 >Reporter: Eli Levine >Assignee: Eli Levine > Fix For: 5.0.0, 4.5.0 > > Attachments: PHOENIX-978.diff > > > CREATE VIEW syntax currently disallows PK constraint to be defined. As a > result views and tenant-specific tables created using CREATE VIEW > automatically inherit their base table's PK with no way to extend it. > Base tables should be allowed to be created with a minimum of PK columns to > support views, and views to extend PKs as desired. This would allow a single > base table to support a heterogeneous set of views on top of it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2058) Check for existence and compatibility of columns being added in view
[ https://issues.apache.org/jira/browse/PHOENIX-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617836#comment-14617836 ] James Taylor commented on PHOENIX-2058: --- Good catch, [~tdsilva]. This seems problematic in general to allow the view to add PK columns - more related to [~elilevine]'s fix for PHOENIX-978. I'll comment over there - I think your code is doing the right thing, though. How about putting together a patch without this new test? > Check for existence and compatibility of columns being added in view > > > Key: PHOENIX-2058 > URL: https://issues.apache.org/jira/browse/PHOENIX-2058 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Thomas D'Silva > Attachments: PHOENIX-2058-WIP.patch, PHOENIX-2058.patch, > PHOENIX-2058.wip.2.patch > > > One check I realized we're not doing, but need to do, is ensuring that the > column being added by the base table doesn't already exist in the view. If > the column does already exist, ideally we can allow the addition to the base > table if the type matches and the scale is null or >= existing scale and the > maxLength is null or >= existing maxLength. Also, if a column is a PK column > and it already exists in the view, the position in the PK must match. > The fact that we've materialized a PTable for the view should make the > addition of this check easier. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-2058) Check for existence and compatibility of columns being added in view
[
https://issues.apache.org/jira/browse/PHOENIX-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617813#comment-14617813
]
Thomas D'Silva edited comment on PHOENIX-2058 at 7/8/15 1:41 AM:
-
[~jamestaylor]
I have uploaded another patch. I have a test that tries to add a pk view column
to the base table that currently fails.
If we have a table with pk B and view with pk B, V1,V2 and we add V1 to the
base table, the test fails when trying to read a row from the base table that
was previously written via the view.
This happens because when it tries to read the rowkey using the table it
assumes that there is no separator, even though the rowkey was written with a
separator.
If I make the following change to the RowKeyValueAccessor constructor
the test passes, but other tests fails. Do what is the right way to handle this
case?
{code}
-this.hasSeparator = !isFixedLength && (datum !=
data.get(data.size()-1));
+this.hasSeparator = !isFixedLength /*&& (datum !=
data.get(data.size()-1))*/;
{code}
was (Author: tdsilva):
[~jamestaylor]
I have uploaded another patch. I have a test that tries to add a pk view column
to the base table that currently fails.
If we have a table with pk B and view with pk B, V1,V2 and we add V1 to the
base table, the test fails when trying to read from the base table that was
previously written to the view.
This happens because when it tries to read the rowkey using the table it
assumes that there is no separator, even though the rowkey was written with a
separator.
If I make the following change to the RowKeyValueAccessor constructor
the test passes, but other tests fails. Do what is the right way to handle this
case?
{code}
-this.hasSeparator = !isFixedLength && (datum !=
data.get(data.size()-1));
+this.hasSeparator = !isFixedLength /*&& (datum !=
data.get(data.size()-1))*/;
{code}
> Check for existence and compatibility of columns being added in view
>
>
> Key: PHOENIX-2058
> URL: https://issues.apache.org/jira/browse/PHOENIX-2058
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-2058-WIP.patch, PHOENIX-2058.patch,
> PHOENIX-2058.wip.2.patch
>
>
> One check I realized we're not doing, but need to do, is ensuring that the
> column being added by the base table doesn't already exist in the view. If
> the column does already exist, ideally we can allow the addition to the base
> table if the type matches and the scale is null or >= existing scale and the
> maxLength is null or >= existing maxLength. Also, if a column is a PK column
> and it already exists in the view, the position in the PK must match.
> The fact that we've materialized a PTable for the view should make the
> addition of this check easier.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2058) Check for existence and compatibility of columns being added in view
[
https://issues.apache.org/jira/browse/PHOENIX-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas D'Silva updated PHOENIX-2058:
Attachment: PHOENIX-2058.patch
[~jamestaylor]
I have uploaded another patch. I have a test that tries to add a pk view column
to the base table that currently fails.
If we have a table with pk B and view with pk B, V1,V2 and we add V1 to the
base table, the test fails when trying to read from the base table that was
previously written to the view.
This happens because when it tries to read the rowkey using the table it
assumes that there is no separator, even though the rowkey was written with a
separator.
If I make the following change to the RowKeyValueAccessor constructor
the test passes, but other tests fails. Do what is the right way to handle this
case?
{code}
-this.hasSeparator = !isFixedLength && (datum !=
data.get(data.size()-1));
+this.hasSeparator = !isFixedLength /*&& (datum !=
data.get(data.size()-1))*/;
{code}
> Check for existence and compatibility of columns being added in view
>
>
> Key: PHOENIX-2058
> URL: https://issues.apache.org/jira/browse/PHOENIX-2058
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-2058-WIP.patch, PHOENIX-2058.patch,
> PHOENIX-2058.wip.2.patch
>
>
> One check I realized we're not doing, but need to do, is ensuring that the
> column being added by the base table doesn't already exist in the view. If
> the column does already exist, ideally we can allow the addition to the base
> table if the type matches and the scale is null or >= existing scale and the
> maxLength is null or >= existing maxLength. Also, if a column is a PK column
> and it already exists in the view, the position in the PK must match.
> The fact that we've materialized a PTable for the view should make the
> addition of this check easier.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PHOENIX-2099) Backward Compatibility - Concurrent modification error on connect
[ https://issues.apache.org/jira/browse/PHOENIX-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva reassigned PHOENIX-2099: --- Assignee: Thomas D'Silva (was: James Taylor) > Backward Compatibility - Concurrent modification error on connect > - > > Key: PHOENIX-2099 > URL: https://issues.apache.org/jira/browse/PHOENIX-2099 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.5.0 >Reporter: Mujtaba Chohan >Assignee: Thomas D'Silva > > With client/server on v4.3.0. Create few tables. Upgrade client/server to > latest 4.x-0.98 and connect: > Exception: > Error: ERROR 301 (23000): Concurrent modification to table. > tableName=SYSTEM.CATALOG (state=23000,code=301) > org.apache.phoenix.schema.ConcurrentTableMutationException: ERROR 301 > (23000): Concurrent modification to table. tableName=SYSTEM.CATALOG > at > org.apache.phoenix.schema.MetaDataClient.processMutationResult(MetaDataClient.java:2223) > at > org.apache.phoenix.schema.MetaDataClient.addColumn(MetaDataClient.java:2518) > at > org.apache.phoenix.jdbc.PhoenixStatement$ExecutableAddColumnStatement$1.execute(PhoenixStatement.java:893) > at > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:303) > at > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:295) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:293) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1189) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.addColumn(ConnectionQueryServicesImpl.java:1836) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.access$600(ConnectionQueryServicesImpl.java:174) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1958) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1868) > at > org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1868) > at > org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:180) > at > org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:132) > at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:151) > at sqlline.SqlLine$DatabaseConnection.connect(SqlLine.java:4650) > at sqlline.SqlLine$DatabaseConnection.getConnection(SqlLine.java:4701) > Also getting the exception when connecting with v4.3.0 on client and latest > 4.x-0.98 on server: > 0: jdbc:phoenix:localhost> ALTER TABLE T1 ADD TESTCOL1 VARCHAR, TESTCOL2 > INTEGER; > Error: ERROR 301 (23000): Concurrent modification to table. tableName=T1 > (state=23000,code=301) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2098) Pig Udf that given a count Reserve chunks of numbers for a sequence
[ https://issues.apache.org/jira/browse/PHOENIX-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617626#comment-14617626 ] Siddhi Mehta commented on PHOENIX-2098: --- [~giacomotaylor],[~jfernando_sfdc] I have a working version for this. https://github.com/siddhimehta/phoenix/commit/7ec6bbad40b0c9cbe61ff099f910fb85144029e6 I was going to wait on PHOENIX-1954 to be commited before I start a pull request. Let me know if I should start the pull request. > Pig Udf that given a count Reserve chunks of numbers for a sequence > --- > > Key: PHOENIX-2098 > URL: https://issues.apache.org/jira/browse/PHOENIX-2098 > Project: Phoenix > Issue Type: New Feature >Reporter: Siddhi Mehta >Assignee: Siddhi Mehta > > Following up on the Jira to bulk reserve sequence's. PHOENIX-1954. > Adding a UDF to enable bulk reserve of sequence's from Pig -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617562#comment-14617562 ] James Taylor commented on PHOENIX-2025: --- [~maghamraviki...@gmail.com] - wouldn't it be correct to use config.getInt(String propName, int defaultValue) with the second arg as the default zookeeper port (as that's what it does)? Thanks in advance for cleaning this up. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617473#comment-14617473 ] ravi commented on PHOENIX-2025: --- Looking into the patch PHOENIX-2025-ClientPortIssue.patch , we are doing a Integer.parseInt on the port property from configuration. In order to ensure we don't run into parsing errors, can we have a check to see for the presence of HBASE_ZOOKEEPER_CLIENT_PORT and in its absence we use HConstants.DEFAULT_ZOOKEPER_CLIENT_PORT . If there is a consensus, I can push a patch. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617392#comment-14617392 ] Hudson commented on PHOENIX-2025: - FAILURE: Integrated in Phoenix-master #816 (See [https://builds.apache.org/job/Phoenix-master/816/]) PHOENIX-2025 Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps (Mujtaba Chohan) (tdsilva: rev dee7a02f92ec3928a76c0d7536bd69f65fb1d4ef) * phoenix-core/src/main/java/org/apache/phoenix/mapreduce/util/ConnectionUtil.java * phoenix-core/src/main/java/org/apache/phoenix/mapreduce/util/PhoenixConfigurationUtil.java > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617320#comment-14617320 ] Josh Mahonin edited comment on PHOENIX-2025 at 7/7/15 8:30 PM: --- [~tdsilva] Sure thing was (Author: jmahonin): @tdsilva Sure thing > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617320#comment-14617320 ] Josh Mahonin commented on PHOENIX-2025: --- @tdsilva Sure thing > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617300#comment-14617300 ] Thomas D'Silva commented on PHOENIX-2025: - [~jamestaylor] [~jmahonin] I will commit this patch. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617294#comment-14617294 ] James Taylor commented on PHOENIX-2025: --- [~jmahonin] - I'm out of the office or would commit myself. Would you have time to commit Mujtaba's fix? We're hoping this gets our builds passing again. For 4.4,4.x, and master branches. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1954) Reserve chunks of numbers for a sequence
[
https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617265#comment-14617265
]
Jan Fernando commented on PHOENIX-1954:
---
I'm don't think that will work but maybe I am missing something :)
The issue stems from the fact that there are 2 incrementValue() methods on
Sequence.java that that executed in succession and invoked from different JDBC
methods. The flow is:
1) Execute expression SELECT NEXT VALUES FOR and update sequence
on the server via stmt.executeQuery()
2) Read back values from expression NEXT VALUES FOR via
rs.next() and rs.getInt()
The calls are:
1) There is incrementValue() that processes the results of the RPC call that
runs within the code synchronized on Sequence.lock() and is part of the flow
that executes the expression.
{code}
public long incrementValue(Result result, ValueOp op, long numToAllocate)
{code}
2) There is incrementValue() that is invoked when the client code executes
rs.next() and called via SequenceTuple.incrementSequenceValues() and is purely
client side code and it is here were we actually need to read the start value
for the bulk allocated range.
{code}
public long incrementValue(long timestamp, ValueOp op, long numToAllocate)
{code}
For this case we need to return the start value from the allocation that
happened which may not be the same as currentValue if NEXT VALUE FOR has been
executed in between. Since it's here that we need to return the start value we
have to cache it on the client separately from currentValue. At the time we get
the value back from the server with #1, since we are still within the
synchronized code, current value on the Result object is correct. However we
read it back asynchronously in #2 we have to store it on the client.
[~jamestaylor] Thoughts?
> Reserve chunks of numbers for a sequence
>
>
> Key: PHOENIX-1954
> URL: https://issues.apache.org/jira/browse/PHOENIX-1954
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Lars Hofhansl
>Assignee: Jan Fernando
> Attachments: PHOENIX-1954-rebased.patch, PHOENIX-1954-wip.patch,
> PHOENIX-1954-wip2.patch.txt, PHOENIX-1954-wip3.patch, PHOENIX-1954-wip4.patch
>
>
> In order to be able to generate many ids in bulk (for example in map reduce
> jobs) we need a way to generate or reserve large sets of ids. We also need to
> mix ids reserved with incrementally generated ids from other clients.
> For this we need to atomically increment the sequence and return the value it
> had when the increment happened.
> If we're OK to throw the current cached set of values away we can do
> {{NEXT VALUE FOR (,)}}, that needs to increment value and return the
> value it incremented from (i.e. it has to throw the current cache away, and
> return the next value it found at the server).
> Or we can invent a new syntax {{RESERVE VALUES FOR , }} that does the
> same, but does not invalidate the cache.
> Note that in either case we won't retrieve the reserved set of values via
> {{NEXT VALUE FOR}} because we'd need to be idempotent in our case, all we
> need to guarantee is that after a call to {{RESERVE VALUES FOR , }},
> which returns a value is that the range [M, M+N) won't be used by any
> other user of the sequence. My might need reserve 1bn ids this way ahead of a
> map reduce run.
> Any better ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2102) phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98
[ https://issues.apache.org/jira/browse/PHOENIX-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617251#comment-14617251 ] James Taylor commented on PHOENIX-2102: --- +1 > phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98 > - > > Key: PHOENIX-2102 > URL: https://issues.apache.org/jira/browse/PHOENIX-2102 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.4.1 >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Fix For: 4.4.1 > > Attachments: PHOENIX-2102.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617248#comment-14617248
]
Hudson commented on PHOENIX-2074:
-
FAILURE: Integrated in Phoenix-master #815 (See
[https://builds.apache.org/job/Phoenix-master/815/])
PHOENIX-2074 StackOverflowError for hash join with round robin (maryannxue: rev
d0c8f9dbd15460c023d50c8b8fd9334fb18c05dc)
*
phoenix-core/src/main/java/org/apache/phoenix/iterate/RoundRobinResultIterator.java
*
phoenix-core/src/it/java/org/apache/phoenix/iterate/RoundRobinResultIteratorIT.java
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2102) phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98
[ https://issues.apache.org/jira/browse/PHOENIX-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Mahonin updated PHOENIX-2102: -- Attachment: PHOENIX-2102.patch For 4.4-HBase-0.98 branch > phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98 > - > > Key: PHOENIX-2102 > URL: https://issues.apache.org/jira/browse/PHOENIX-2102 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.4.1 >Reporter: Josh Mahonin >Assignee: Josh Mahonin > Fix For: 4.4.1 > > Attachments: PHOENIX-2102.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2102) phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98
Josh Mahonin created PHOENIX-2102: - Summary: phoenix-pherf: Wrong parent pom version in 4.4-HBase-0.98 Key: PHOENIX-2102 URL: https://issues.apache.org/jira/browse/PHOENIX-2102 Project: Phoenix Issue Type: Bug Reporter: Josh Mahonin Assignee: Josh Mahonin -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2063) Row value constructor doesn't work when used in COUNT DISTINCT
[
https://issues.apache.org/jira/browse/PHOENIX-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617140#comment-14617140
]
ramkrishna.s.vasudevan commented on PHOENIX-2063:
-
Because it is a count the ResultSet.next() would be called only once. This is
from the client side. But on the server side a distinct set of values should be
retrieved right?
Let me check the code and see what is happening here.
> Row value constructor doesn't work when used in COUNT DISTINCT
> --
>
> Key: PHOENIX-2063
> URL: https://issues.apache.org/jira/browse/PHOENIX-2063
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Dumindu Buddhika
> Attachments: PHOENIX-2063-v1.patch
>
>
> As a workaround for PHOENIX-2062, I tried the following query:
> {code}
> SELECT COUNT(DISTINCT (a.col1, b.col2)) ...
> {code}
> However, this always returns 1 as the COUNT DISTINCT which is wrong.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617055#comment-14617055 ] James Taylor commented on PHOENIX-2025: --- [~tdsilva] or [~maghamravikiran] - mind committing? Looks like Mujtaba is on PTO today. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2099) Backward Compatibility - Concurrent modification error on connect
[ https://issues.apache.org/jira/browse/PHOENIX-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617046#comment-14617046 ] James Taylor commented on PHOENIX-2099: --- [~tdsilva] - would you mind taking a look at this one after PHOENIX-2058? > Backward Compatibility - Concurrent modification error on connect > - > > Key: PHOENIX-2099 > URL: https://issues.apache.org/jira/browse/PHOENIX-2099 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.5.0 >Reporter: Mujtaba Chohan >Assignee: James Taylor > > With client/server on v4.3.0. Create few tables. Upgrade client/server to > latest 4.x-0.98 and connect: > Exception: > Error: ERROR 301 (23000): Concurrent modification to table. > tableName=SYSTEM.CATALOG (state=23000,code=301) > org.apache.phoenix.schema.ConcurrentTableMutationException: ERROR 301 > (23000): Concurrent modification to table. tableName=SYSTEM.CATALOG > at > org.apache.phoenix.schema.MetaDataClient.processMutationResult(MetaDataClient.java:2223) > at > org.apache.phoenix.schema.MetaDataClient.addColumn(MetaDataClient.java:2518) > at > org.apache.phoenix.jdbc.PhoenixStatement$ExecutableAddColumnStatement$1.execute(PhoenixStatement.java:893) > at > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:303) > at > org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:295) > at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:293) > at > org.apache.phoenix.jdbc.PhoenixStatement.executeUpdate(PhoenixStatement.java:1189) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.addColumn(ConnectionQueryServicesImpl.java:1836) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.access$600(ConnectionQueryServicesImpl.java:174) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1958) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(ConnectionQueryServicesImpl.java:1868) > at > org.apache.phoenix.util.PhoenixContextExecutor.call(PhoenixContextExecutor.java:77) > at > org.apache.phoenix.query.ConnectionQueryServicesImpl.init(ConnectionQueryServicesImpl.java:1868) > at > org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:180) > at > org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.connect(PhoenixEmbeddedDriver.java:132) > at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:151) > at sqlline.SqlLine$DatabaseConnection.connect(SqlLine.java:4650) > at sqlline.SqlLine$DatabaseConnection.getConnection(SqlLine.java:4701) > Also getting the exception when connecting with v4.3.0 on client and latest > 4.x-0.98 on server: > 0: jdbc:phoenix:localhost> ALTER TABLE T1 ADD TESTCOL1 VARCHAR, TESTCOL2 > INTEGER; > Error: ERROR 301 (23000): Concurrent modification to table. tableName=T1 > (state=23000,code=301) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1954) Reserve chunks of numbers for a sequence
[
https://issues.apache.org/jira/browse/PHOENIX-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617043#comment-14617043
]
James Taylor commented on PHOENIX-1954:
---
Good catch, [~jfernando_sfdc]. Instead of managing this race condition on the
client with an additional Map and Queue, how about if the server adds the extra
required state to the Result object instead? I think that'd get rid of the race
condition and be a bit simpler.
> Reserve chunks of numbers for a sequence
>
>
> Key: PHOENIX-1954
> URL: https://issues.apache.org/jira/browse/PHOENIX-1954
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Lars Hofhansl
>Assignee: Jan Fernando
> Attachments: PHOENIX-1954-rebased.patch, PHOENIX-1954-wip.patch,
> PHOENIX-1954-wip2.patch.txt, PHOENIX-1954-wip3.patch, PHOENIX-1954-wip4.patch
>
>
> In order to be able to generate many ids in bulk (for example in map reduce
> jobs) we need a way to generate or reserve large sets of ids. We also need to
> mix ids reserved with incrementally generated ids from other clients.
> For this we need to atomically increment the sequence and return the value it
> had when the increment happened.
> If we're OK to throw the current cached set of values away we can do
> {{NEXT VALUE FOR (,)}}, that needs to increment value and return the
> value it incremented from (i.e. it has to throw the current cache away, and
> return the next value it found at the server).
> Or we can invent a new syntax {{RESERVE VALUES FOR , }} that does the
> same, but does not invalidate the cache.
> Note that in either case we won't retrieve the reserved set of values via
> {{NEXT VALUE FOR}} because we'd need to be idempotent in our case, all we
> need to guarantee is that after a call to {{RESERVE VALUES FOR , }},
> which returns a value is that the range [M, M+N) won't be used by any
> other user of the sequence. My might need reserve 1bn ids this way ahead of a
> map reduce run.
> Any better ideas?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617016#comment-14617016
]
James Taylor commented on PHOENIX-2074:
---
Yes, 4.x,4.4, and master.
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617011#comment-14617011
]
Maryann Xue commented on PHOENIX-2074:
--
Ok. I'll commit the current fix first, and try to test the corner case you just
mentioned. So commit to master, 4.x, and 4.4 branches?
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2074) StackOverflowError for hash join with round robin
[
https://issues.apache.org/jira/browse/PHOENIX-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616845#comment-14616845
]
James Taylor commented on PHOENIX-2074:
---
[~jmahonin] - you might try running a major compaction as that'll generate
stats as well.
[~maryannxue] - any luck repro-ing? Maybe it's best if we just commit your
potential fix as it won't do any harm. One corner case is when the region
boundary cache is detected to be out of date due to a split - maybe this issue
is triggered then?
> StackOverflowError for hash join with round robin
> -
>
> Key: PHOENIX-2074
> URL: https://issues.apache.org/jira/browse/PHOENIX-2074
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
> Attachments: PHOENIX-2074.patch
>
>
> EVENTS Table has id,article, and more columns. Id is the primay key
> MAPPING Table has id,article,category columns. Id is the primay key
> There is index on article column of both the tables.
> Below is the query.
> select count(MAPPING.article) as cnt,MAPPING.category from EVENTS
> join
> MAPPING on MAPPING.article = EVENTS.article
> group by category order by cnt ;
> Here's the stack trace:
> {code}
> Error: Encountered exception in sub plan [0] execution. (state=,code=0)
> java.sql.SQLException: Encountered exception in sub plan [0] execution.
> at
> org.apache.phoenix.execute.HashJoinPlan.iterator(HashJoinPlan.java:156)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:251)
> at
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:241)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:240)
> at
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1250)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:808)
> at sqlline.SqlLine.begin(SqlLine.java:681)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.StackOverflowError
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> at
> org.apache.phoenix.iterate.RoundRobinResultIterator$RoundRobinIterator.close(RoundRobinResultIterator.java:298)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Error in pom.xml and a procedure question
I'd go ahead and create a JIRA as it makes it easier to track. On Tuesday, July 7, 2015, Josh Mahonin wrote: > The phoenix-pherf/pom.xml in the 4.4-HBase-0.98 branch has a wrong parent > pom version. I think the other branches are OK though: > https://github.com/apache/phoenix/blob/4.4-HBase-0.98/phoenix-pherf/pom.xml > > For small fixes like this, does making a JIRA ticket make sense? Is an > email ack / nack thread the right thing to do? > > Thanks! > > Josh >
[jira] [Commented] (PHOENIX-2025) Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting up in client apps
[ https://issues.apache.org/jira/browse/PHOENIX-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616801#comment-14616801 ] James Taylor commented on PHOENIX-2025: --- +1 for the fix. Thanks, [~mujtabachohan]. > Phoenix-core's hbase-default.xml prevents HBaseTestingUtility from starting > up in client apps > - > > Key: PHOENIX-2025 > URL: https://issues.apache.org/jira/browse/PHOENIX-2025 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.3.0 >Reporter: Geoffrey Jacoby >Assignee: Geoffrey Jacoby > Fix For: 5.0.0, 4.5.0, 4.4.1 > > Attachments: PHOENIX-2025-ClientPortIssue.patch, PHOENIX-2025.patch, > PHOENIX-2025_v2.patch > > > Phoenix seems to have long had its own version of hbase-default.xml as a test > resource in phoenix-core with a single setting to override > hbase.defaults.for.version.skip to true. Sometime around Phoenix 4.3, > phoenix-core seems to have been split into a main jar and a test jar, and the > hbase-default.xml went into the test jar. > The odd result of this is that in client apps that include the test jar, the > classloader in HBaseConfiguration.create() now sees Phoenix's > hbase-default.xml, rather than HBase's, and creates a Configuration object > without HBase's defaults. One major consequence of this is that the > HBaseTestingUtility can't start up, because it relies on those HBase defaults > being set. This is a huge problem in a client app that includes the > phoenix-core test jar in order to make use of the PhoenixTestDriver and > BaseTest classes; the upgrade to 4.3 breaks all tests using the > HBaseTestingUtility. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Error in pom.xml and a procedure question
The phoenix-pherf/pom.xml in the 4.4-HBase-0.98 branch has a wrong parent pom version. I think the other branches are OK though: https://github.com/apache/phoenix/blob/4.4-HBase-0.98/phoenix-pherf/pom.xml For small fixes like this, does making a JIRA ticket make sense? Is an email ack / nack thread the right thing to do? Thanks! Josh
