[jira] [Created] (PHOENIX-4158) Upgrade Phoenix-core servlet-api dependency
jianhaozh created PHOENIX-4158: -- Summary: Upgrade Phoenix-core servlet-api dependency Key: PHOENIX-4158 URL: https://issues.apache.org/jira/browse/PHOENIX-4158 Project: Phoenix Issue Type: Wish Affects Versions: 4.11.0 Reporter: jianhaozh As the summary memtioned ,I found the phoenix-core using an old version of servlet-api @ 2.5, it seems an very old version of servlet api, when i want to integrate the phoenix query functions in my web application ,then jar conflicts with my maven config which is an version @3.0+, So does the Phoenix Dev group have any plan to upgrade the servlet-api ? Any reply will be appreciated! thankx -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-2314) Cannot prepare parameterized statement with a 'like' predicate
[
https://issues.apache.org/jira/browse/PHOENIX-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152072#comment-16152072
]
Kevin Liew commented on PHOENIX-2314:
-
Failures seem unrelated to patch. Will commit.
> Cannot prepare parameterized statement with a 'like' predicate
> --
>
> Key: PHOENIX-2314
> URL: https://issues.apache.org/jira/browse/PHOENIX-2314
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.5.2
> Environment: Using Fiddler or cURL to communicate with a Phoenix
> 4.5.2 queryserver using Avatica wire protocol
>Reporter: Kevin Liew
>Assignee: Kevin Liew
> Labels: avatica, phoenix
> Fix For: 4.12.0
>
> Attachments: PHOENIX-2314.2.patch, PHOENIX-2314.3.patch,
> PHOENIX-2314.4.patch, PHOENIX-2314.5.patch, PHOENIX-2314.patch
>
>
> *POST*
> {noformat}
> request: { "request":"prepare",
> "connectionId":"1646a1b9-334e-4a21-ade8-47c3d0c8e5a3", "sql":"select * from
> emp where first_name like ?", "maxRowCount":-1 }
> Host: 192.168.203.156:8765
> Content-Length: 0
> {noformat}
> _select * from emp where first_name like ?_
> *RESPONSE*
> {noformat}
> HTTP/1.1 500 org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. BOOLEAN for null
> Date: Wed, 07 Oct 2015 22:42:26 GMT
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Type: text/html; charset=ISO-8859-1
> Content-Length: 368
> Connection: close
> Server: Jetty(9.2.z-SNAPSHOT)
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005):
> Type mismatch. BOOLEAN for null
> Powered by Jetty://
>
>
> {noformat}
> _org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. BOOLEAN for null_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4157) I am currently facing issue with namedparameters apache phoneix for 'like ' keyword
[
https://issues.apache.org/jira/browse/PHOENIX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Reddy updated PHOENIX-4157:
--
Description:
uncategorized SQLException for SQL [select * from customers where customer like
'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
(0) : while preparing SQL: select * from customers where customer like ?;
nested exception is org.apache.calcite.avatica.AvaticaSqlException:
This happening when I use below query with named parameter
searchOrderQuery = new StringBuilder("select * from customers where customer
like :customerName");
and if I replace named parameter then it is working fine
searchOrderQuery = new StringBuilder("select * from customers where customer
like '%rajesh%' ");
**Note:It is happening only for like statement and not for others
was:
uncategorized SQLException for SQL [select * from orders where customer like
'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
(0) : while preparing SQL: select * from orders where customer like
'customer%' and user like ?; nested exception is
org.apache.calcite.avatica.AvaticaSqlException:
This happening when I below query with named parameter
searchOrderQuery = new StringBuilder("select * from customer where customer
like :customerName");
and if I replace name parameter then it is working fine
searchOrderQuery = new StringBuilder("select * from customer where customer
like '%rajesh%' ");
**Note:It is happening only for like statement and not for others
> I am currently facing issue with namedparameters apache phoneix for 'like '
> keyword
> ---
>
> Key: PHOENIX-4157
> URL: https://issues.apache.org/jira/browse/PHOENIX-4157
> Project: Phoenix
> Issue Type: Bug
>Reporter: Prasad Reddy
>
> uncategorized SQLException for SQL [select * from customers where customer
> like 'customer%' and user like ?]; SQL state [0]; error code [-1]; Error
> -1 (0) : while preparing SQL: select * from customers where customer
> like ?; nested exception is org.apache.calcite.avatica.AvaticaSqlException:
> This happening when I use below query with named parameter
> searchOrderQuery = new StringBuilder("select * from customers where customer
> like :customerName");
> and if I replace named parameter then it is working fine
> searchOrderQuery = new StringBuilder("select * from customers where customer
> like '%rajesh%' ");
> **Note:It is happening only for like statement and not for others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4157) I am currently facing issue with namedparameters apache phoneix for 'like ' keyword
[
https://issues.apache.org/jira/browse/PHOENIX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Reddy updated PHOENIX-4157:
--
Summary: I am currently facing issue with namedparameters apache phoneix
for 'like ' keyword (was: I am currently facing issue namedparameters apache
phoneix for 'like ' keyword)
> I am currently facing issue with namedparameters apache phoneix for 'like '
> keyword
> ---
>
> Key: PHOENIX-4157
> URL: https://issues.apache.org/jira/browse/PHOENIX-4157
> Project: Phoenix
> Issue Type: Bug
>Reporter: Prasad Reddy
>
> uncategorized SQLException for SQL [select * from orders where customer like
> 'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
> (0) : while preparing SQL: select * from orders where customer like
> 'customer%' and user like ?; nested exception is
> org.apache.calcite.avatica.AvaticaSqlException:
> This happening when I below query with named parameter
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like :customerName");
> and if I replace name parameter then it is working fine
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like '%rajesh%' ");
> **Note:It is happening only for like statement and not for others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4157) I am currently facing issue namedparameters apache phoneix for 'like ' keyword
[
https://issues.apache.org/jira/browse/PHOENIX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Reddy updated PHOENIX-4157:
--
Summary: I am currently facing issue namedparameters apache phoneix for
'like ' keyword (was: I am currently facing issue namedparameters from Java)
> I am currently facing issue namedparameters apache phoneix for 'like ' keyword
> --
>
> Key: PHOENIX-4157
> URL: https://issues.apache.org/jira/browse/PHOENIX-4157
> Project: Phoenix
> Issue Type: Bug
>Reporter: Prasad Reddy
>
> uncategorized SQLException for SQL [select * from orders where customer like
> 'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
> (0) : while preparing SQL: select * from orders where customer like
> 'customer%' and user like ?; nested exception is
> org.apache.calcite.avatica.AvaticaSqlException:
> This happening when I below query with named parameter
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like :customerName");
> and if I replace name parameter then it is working fine
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like '%rajesh%' ");
> **Note:It is happening only for like statement and not for others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4157) I am currently facing issue namedparameters from Java
[
https://issues.apache.org/jira/browse/PHOENIX-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prasad Reddy updated PHOENIX-4157:
--
Description:
uncategorized SQLException for SQL [select * from orders where customer like
'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
(0) : while preparing SQL: select * from orders where customer like
'customer%' and user like ?; nested exception is
org.apache.calcite.avatica.AvaticaSqlException:
This happening when I below query with named parameter
searchOrderQuery = new StringBuilder("select * from customer where customer
like :customerName");
and if I replace name parameter then it is working fine
searchOrderQuery = new StringBuilder("select * from customer where customer
like '%rajesh%' ");
**Note:It is happening only for like statement and not for others
was:
uncategorized SQLException for SQL [select * from orders where customer like
'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
(0) : while preparing SQL: select * from orders where customer like
'customer%' and user like ?; nested exception is
org.apache.calcite.avatica.AvaticaSqlException:
This happening when I below query with named parameter
searchOrderQuery = new StringBuilder("select * from customer where customer
like :customerName");
and if I replace name parameter then it is working fine
searchOrderQuery = new StringBuilder("select * from customer where customer
like '%rajesh%' ");
> I am currently facing issue namedparameters from Java
> -
>
> Key: PHOENIX-4157
> URL: https://issues.apache.org/jira/browse/PHOENIX-4157
> Project: Phoenix
> Issue Type: Bug
>Reporter: Prasad Reddy
>
> uncategorized SQLException for SQL [select * from orders where customer like
> 'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
> (0) : while preparing SQL: select * from orders where customer like
> 'customer%' and user like ?; nested exception is
> org.apache.calcite.avatica.AvaticaSqlException:
> This happening when I below query with named parameter
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like :customerName");
> and if I replace name parameter then it is working fine
> searchOrderQuery = new StringBuilder("select * from customer where customer
> like '%rajesh%' ");
> **Note:It is happening only for like statement and not for others
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (PHOENIX-4157) I am currently facing issue namedparameters from Java
Prasad Reddy created PHOENIX-4157:
-
Summary: I am currently facing issue namedparameters from Java
Key: PHOENIX-4157
URL: https://issues.apache.org/jira/browse/PHOENIX-4157
Project: Phoenix
Issue Type: Bug
Reporter: Prasad Reddy
uncategorized SQLException for SQL [select * from orders where customer like
'customer%' and user like ?]; SQL state [0]; error code [-1]; Error -1
(0) : while preparing SQL: select * from orders where customer like
'customer%' and user like ?; nested exception is
org.apache.calcite.avatica.AvaticaSqlException:
This happening when I below query with named parameter
searchOrderQuery = new StringBuilder("select * from customer where customer
like :customerName");
and if I replace name parameter then it is working fine
searchOrderQuery = new StringBuilder("select * from customer where customer
like '%rajesh%' ");
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4156) Fix flapping MutableIndexFailureIT
[
https://issues.apache.org/jira/browse/PHOENIX-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152018#comment-16152018
]
Hadoop QA commented on PHOENIX-4156:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12885168/PHOENIX-4156_v1.patch
against master branch at commit f03c43bdd2abb18f3a1edbc717340b52b529fb48.
ATTACHMENT ID: 12885168
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+0 tests included{color}. The patch appears to be a
documentation, build,
or dev patch that doesn't require tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ClientTimeArithmeticQueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TableSnapshotReadsMapReduceIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1365//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1365//console
This message is automatically generated.
> Fix flapping MutableIndexFailureIT
> --
>
> Key: PHOENIX-4156
> URL: https://issues.apache.org/jira/browse/PHOENIX-4156
> Project: Phoenix
> Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-4156_v1.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-2314) Cannot prepare parameterized statement with a 'like' predicate
[
https://issues.apache.org/jira/browse/PHOENIX-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16152002#comment-16152002
]
Hadoop QA commented on PHOENIX-2314:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12885167/PHOENIX-2314.5.patch
against master branch at commit f03c43bdd2abb18f3a1edbc717340b52b529fb48.
ATTACHMENT ID: 12885167
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.TableSnapshotReadsMapReduceIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1364//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1364//console
This message is automatically generated.
> Cannot prepare parameterized statement with a 'like' predicate
> --
>
> Key: PHOENIX-2314
> URL: https://issues.apache.org/jira/browse/PHOENIX-2314
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.5.2
> Environment: Using Fiddler or cURL to communicate with a Phoenix
> 4.5.2 queryserver using Avatica wire protocol
>Reporter: Kevin Liew
>Assignee: Kevin Liew
> Labels: avatica, phoenix
> Fix For: 4.12.0
>
> Attachments: PHOENIX-2314.2.patch, PHOENIX-2314.3.patch,
> PHOENIX-2314.4.patch, PHOENIX-2314.5.patch, PHOENIX-2314.patch
>
>
> *POST*
> {noformat}
> request: { "request":"prepare",
> "connectionId":"1646a1b9-334e-4a21-ade8-47c3d0c8e5a3", "sql":"select * from
> emp where first_name like ?", "maxRowCount":-1 }
> Host: 192.168.203.156:8765
> Content-Length: 0
> {noformat}
> _select * from emp where first_name like ?_
> *RESPONSE*
> {noformat}
> HTTP/1.1 500 org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. BOOLEAN for null
> Date: Wed, 07 Oct 2015 22:42:26 GMT
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Type: text/html; charset=ISO-8859-1
> Content-Length: 368
> Connection: close
> Server: Jetty(9.2.z-SNAPSHOT)
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005):
> Type mismatch. BOOLEAN for null
> Powered by Jetty://
>
>
> {noformat}
> _org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. BOOLEAN for null_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (PHOENIX-4156) Fix flapping MutableIndexFailureIT
[ https://issues.apache.org/jira/browse/PHOENIX-4156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samarth Jain updated PHOENIX-4156: -- Attachment: PHOENIX-4156_v1.patch Patch to log the state of the index. I think there is likely a race condition between index rebuild task and our test. That would require us to do some refactoring of code to make sure the rebuild task can be kicked off synchronously. > Fix flapping MutableIndexFailureIT > -- > > Key: PHOENIX-4156 > URL: https://issues.apache.org/jira/browse/PHOENIX-4156 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Attachments: PHOENIX-4156_v1.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-2314) Cannot prepare parameterized statement with a 'like' predicate
[
https://issues.apache.org/jira/browse/PHOENIX-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated PHOENIX-2314:
Attachment: PHOENIX-2314.5.patch
> Cannot prepare parameterized statement with a 'like' predicate
> --
>
> Key: PHOENIX-2314
> URL: https://issues.apache.org/jira/browse/PHOENIX-2314
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.5.2
> Environment: Using Fiddler or cURL to communicate with a Phoenix
> 4.5.2 queryserver using Avatica wire protocol
>Reporter: Kevin Liew
>Assignee: Kevin Liew
> Labels: avatica, phoenix
> Fix For: 4.12.0
>
> Attachments: PHOENIX-2314.2.patch, PHOENIX-2314.3.patch,
> PHOENIX-2314.4.patch, PHOENIX-2314.5.patch, PHOENIX-2314.patch
>
>
> *POST*
> {noformat}
> request: { "request":"prepare",
> "connectionId":"1646a1b9-334e-4a21-ade8-47c3d0c8e5a3", "sql":"select * from
> emp where first_name like ?", "maxRowCount":-1 }
> Host: 192.168.203.156:8765
> Content-Length: 0
> {noformat}
> _select * from emp where first_name like ?_
> *RESPONSE*
> {noformat}
> HTTP/1.1 500 org.apache.phoenix.schema.TypeMismatchException: ERROR 203
> (22005): Type mismatch. BOOLEAN for null
> Date: Wed, 07 Oct 2015 22:42:26 GMT
> Cache-Control: must-revalidate,no-cache,no-store
> Content-Type: text/html; charset=ISO-8859-1
> Content-Length: 368
> Connection: close
> Server: Jetty(9.2.z-SNAPSHOT)
>
>
>
> Error 500
>
>
> HTTP ERROR: 500
> Problem accessing /. Reason:
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005):
> Type mismatch. BOOLEAN for null
> Powered by Jetty://
>
>
> {noformat}
> _org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type
> mismatch. BOOLEAN for null_
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Question about memory chunk and waiting for memory to become free
Hi, just looking at MemoryChunk for various reasons. What I did not realize is that when no memory is currently available the implementation waits for memory to become available.The default wait time is 10s. This seems very dangerous to me. This can hang HBase handler threads at various points, especially when Phoenix is "busy" (I realize we're not talking about real memory here, but the effect is still that the HBase server threads would stall). HBase was designed with the assumption that individual RPCs do not tie up a handler thread for long. (The worst offender is a scan RPC that could scan up to a region's worth if a highly selective filter was passed). It's also possible that this is mostly used in asynchronous processing, although a quick scan of the code suggests that's not the case. It's possible that I'm missing something (in which case someone enlighten me please). I feel with wait time should be set to 0. I.e. we check whether there's memory available right now, if not we just fail the request and free the handler thread. I'd even argue we can remove the wait/synchronization code completely from MemoryChunk. Comments? -- Lars
[jira] [Created] (PHOENIX-4156) Fix flapping MutableIndexFailureIT
Samarth Jain created PHOENIX-4156: - Summary: Fix flapping MutableIndexFailureIT Key: PHOENIX-4156 URL: https://issues.apache.org/jira/browse/PHOENIX-4156 Project: Phoenix Issue Type: Bug Reporter: Samarth Jain Assignee: Samarth Jain -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4155) Convert CreateTableIT to extend ParallelStatsDisabledIT
[ https://issues.apache.org/jira/browse/PHOENIX-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151767#comment-16151767 ] Hudson commented on PHOENIX-4155: - FAILURE: Integrated in Jenkins build Phoenix-master #1767 (See [https://builds.apache.org/job/Phoenix-master/1767/]) PHOENIX-4155 Convert CreateTableIT to extend ParallelStatsDisabledIT (samarth: rev f03c43bdd2abb18f3a1edbc717340b52b529fb48) * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/CreateTableIT.java > Convert CreateTableIT to extend ParallelStatsDisabledIT > --- > > Key: PHOENIX-4155 > URL: https://issues.apache.org/jira/browse/PHOENIX-4155 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Fix For: 4.12.0 > > Attachments: PHOENIX-4155.patch > > > Also, get rid of all the SCN stuff in the tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-153) Implement TABLESAMPLE clause
[ https://issues.apache.org/jira/browse/PHOENIX-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151751#comment-16151751 ] hanzhi commented on PHOENIX-153: Awesome!! > Implement TABLESAMPLE clause > > > Key: PHOENIX-153 > URL: https://issues.apache.org/jira/browse/PHOENIX-153 > Project: Phoenix > Issue Type: Task >Reporter: James Taylor >Assignee: Ethan Wang > Labels: enhancement > Fix For: 4.12.0 > > Attachments: Sampling_Accuracy_Performance.jpg > > > Support the standard SQL TABLESAMPLE clause by implementing a filter that > uses a skip next hint based on the region boundaries of the table to only > return n rows per region. > [Update] > Source Code Patch: > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commitdiff;h=5e33dc12bc088bd0008d89f0a5cd7d5c368efa25 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (PHOENIX-4155) Convert CreateTableIT to extend ParallelStatsDisabledIT
[ https://issues.apache.org/jira/browse/PHOENIX-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samarth Jain resolved PHOENIX-4155. --- Resolution: Fixed Fix Version/s: 4.12.0 > Convert CreateTableIT to extend ParallelStatsDisabledIT > --- > > Key: PHOENIX-4155 > URL: https://issues.apache.org/jira/browse/PHOENIX-4155 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Fix For: 4.12.0 > > Attachments: PHOENIX-4155.patch > > > Also, get rid of all the SCN stuff in the tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4155) Convert CreateTableIT to extend ParallelStatsDisabledIT
[ https://issues.apache.org/jira/browse/PHOENIX-4155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samarth Jain updated PHOENIX-4155: -- Attachment: PHOENIX-4155.patch > Convert CreateTableIT to extend ParallelStatsDisabledIT > --- > > Key: PHOENIX-4155 > URL: https://issues.apache.org/jira/browse/PHOENIX-4155 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Attachments: PHOENIX-4155.patch > > > Also, get rid of all the SCN stuff in the tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (PHOENIX-4155) Convert CreateTableIT to extend ParallelStatsDisabledIT
Samarth Jain created PHOENIX-4155: - Summary: Convert CreateTableIT to extend ParallelStatsDisabledIT Key: PHOENIX-4155 URL: https://issues.apache.org/jira/browse/PHOENIX-4155 Project: Phoenix Issue Type: Bug Reporter: Samarth Jain Assignee: Samarth Jain Also, get rid of all the SCN stuff in the tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (PHOENIX-4151) Tests extending BaseQueryIT are flapping
[
https://issues.apache.org/jira/browse/PHOENIX-4151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samarth Jain updated PHOENIX-4151:
--
Attachment: PHOENIX-4151_wip.patch
Attaching a work in progress patch. Some tests do rely on the timestamp. I am
inclined to comment them out or tweak them. Or maybe not have them test out the
indexing code path.
> Tests extending BaseQueryIT are flapping
>
>
> Key: PHOENIX-4151
> URL: https://issues.apache.org/jira/browse/PHOENIX-4151
> Project: Phoenix
> Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Samarth Jain
> Attachments: PHOENIX-4151_wip.patch
>
>
> Sample failures:
> {code}
> ERROR]
> testNotInListOfFloat[NotQueryIT_1](org.apache.phoenix.end2end.NotQueryIT)
> Time elapsed: 0.001 s <<< ERROR!
> java.lang.RuntimeException: java.sql.SQLTimeoutException: Operation timed out.
> at org.apache.phoenix.end2end.NotQueryIT.(NotQueryIT.java:56)
> Caused by: java.sql.SQLTimeoutException: Operation timed out.
> at org.apache.phoenix.end2end.NotQueryIT.(NotQueryIT.java:56)
> {code}
> {code}
> [ERROR] testValidStringConcatExpression[indexDDL=CREATE INDEX %s ON %s
> (a_integer, a_string) INCLUDE (B_STRING, A_DATE)
> %s,mutable=false,columnEncoded=false](org.apache.phoenix.end2end.QueryIT)
> Time elapsed: 0.014 s <<< ERROR!
> java.lang.RuntimeException: java.sql.SQLTimeoutException: Operation timed out.
> at org.apache.phoenix.end2end.QueryIT.(QueryIT.java:66)
> Caused by: java.sql.SQLTimeoutException: Operation timed out.
> at org.apache.phoenix.end2end.QueryIT.(QueryIT.java:66)
> {code}
> {code}
> [ERROR]
> testNullMultiCondCaseStatement[CaseStatementIT_1](org.apache.phoenix.end2end.CaseStatementIT)
> Time elapsed: 0.007 s <<< ERROR!
> java.lang.RuntimeException: java.sql.SQLTimeoutException: Operation timed out.
> at
> org.apache.phoenix.end2end.CaseStatementIT.(CaseStatementIT.java:58)
> Caused by: java.sql.SQLTimeoutException: Operation timed out.
> at
> org.apache.phoenix.end2end.CaseStatementIT.(CaseStatementIT.java:58)
> {code}
> My hunch is that timeouts are happening when creating tables or indices.
> Probably some sort of a timestamp/scn issue. [~jamestaylor] - any ideas?
> Would injecting our own clock in EnvironmentEdge help?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (PHOENIX-4110) Shutdown mini cluster when number of tables grows beyond a threshold
[ https://issues.apache.org/jira/browse/PHOENIX-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151708#comment-16151708 ] James Taylor commented on PHOENIX-4110: --- +1 > Shutdown mini cluster when number of tables grows beyond a threshold > > > Key: PHOENIX-4110 > URL: https://issues.apache.org/jira/browse/PHOENIX-4110 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Attachments: PHOENIX-4110_addendum_4.x-HBase-0.98.patch, > PHOENIX-4110.patch, PHOENIX-4110_v10.patch, PHOENIX-4110_v10.patch, > PHOENIX-4110_V2_4.x-HBase-0.98.patch, PHOENIX-4110_v3_4.x-HBase-0.98.patch, > PHOENIX-4110_v3.patch, PHOENIX-4110_v4.patch, PHOENIX-4110_v5.patch, > PHOENIX-4110_v6.patch, PHOENIX-4110_v7.patch, PHOENIX-4110_v8.patch, > PHOENIX-4110_v9.patch > > > ParallelRunListener today monitors the number of tests that have been run to > determine when mini cluster should be shut down. This helps prevent our test > JVM forks running in OOM. A better heuristic would be to instead check the > number of tables that were created by tests. This way when a particular test > class has created lots of tables, we can shut down the mini cluster sooner. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (PHOENIX-4110) Shutdown mini cluster when number of tables grows beyond a threshold
[ https://issues.apache.org/jira/browse/PHOENIX-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16151706#comment-16151706 ] Samarth Jain commented on PHOENIX-4110: --- Will go ahead and commit the addendum for 4.x-HBase-0.98 branch since my local run passed. > Shutdown mini cluster when number of tables grows beyond a threshold > > > Key: PHOENIX-4110 > URL: https://issues.apache.org/jira/browse/PHOENIX-4110 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: Samarth Jain > Attachments: PHOENIX-4110_addendum_4.x-HBase-0.98.patch, > PHOENIX-4110.patch, PHOENIX-4110_v10.patch, PHOENIX-4110_v10.patch, > PHOENIX-4110_V2_4.x-HBase-0.98.patch, PHOENIX-4110_v3_4.x-HBase-0.98.patch, > PHOENIX-4110_v3.patch, PHOENIX-4110_v4.patch, PHOENIX-4110_v5.patch, > PHOENIX-4110_v6.patch, PHOENIX-4110_v7.patch, PHOENIX-4110_v8.patch, > PHOENIX-4110_v9.patch > > > ParallelRunListener today monitors the number of tests that have been run to > determine when mini cluster should be shut down. This helps prevent our test > JVM forks running in OOM. A better heuristic would be to instead check the > number of tables that were created by tests. This way when a particular test > class has created lots of tables, we can shut down the mini cluster sooner. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
