[jira] [Commented] (TRAFODION-2003) Some classes named with the prefix HP instead of Traf
[ https://issues.apache.org/jira/browse/TRAFODION-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290527#comment-15290527 ] ASF GitHub Bot commented on TRAFODION-2003: --- GitHub user kevinxu021 opened a pull request: https://github.com/apache/incubator-trafodion/pull/491 [TRAFODION-2003]Rename to Traf* You can merge this pull request into a Git repository by running: $ git pull https://github.com/kevinxu021/incubator-trafodion t4-rename Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/491.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #491 commit 38e49cf712cac614349c024af5125955101abb10 Author: Kevin Xu Date: 2016-05-13T07:41:52Z Rename required prefix with Traf > Some classes named with the prefix HP instead of Traf > - > > Key: TRAFODION-2003 > URL: https://issues.apache.org/jira/browse/TRAFODION-2003 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Reporter: Kevin Xu > > Some classes named with the prefix HP instead of Traf. It's not consistent > while the others start Traf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2003) Some classes named with the prefix HP instead of Traf
Kevin Xu created TRAFODION-2003: --- Summary: Some classes named with the prefix HP instead of Traf Key: TRAFODION-2003 URL: https://issues.apache.org/jira/browse/TRAFODION-2003 Project: Apache Trafodion Issue Type: Bug Components: client-jdbc-t4 Reporter: Kevin Xu Some classes named with the prefix HP instead of Traf. It's not consistent while the others start Traf. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-762) LP Bug: 1392452 - Support new Hive data types such as CHAR
[ https://issues.apache.org/jira/browse/TRAFODION-762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290478#comment-15290478 ] liu ming commented on TRAFODION-762: I volunteer to do this. I want to do this incrementally, first iteration is to support DATE and VARCHAR, if possible. > LP Bug: 1392452 - Support new Hive data types such as CHAR > -- > > Key: TRAFODION-762 > URL: https://issues.apache.org/jira/browse/TRAFODION-762 > Project: Apache Trafodion > Issue Type: Wish > Components: sql-cmp >Reporter: Hans Zeller >Assignee: liu ming >Priority: Minor > > Hive now seems to support data types that match Trafodion types very well. > According to > https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Create/Drop/TruncateTable > Hive 0.11 supports DECIMAL > Hive 0.12 supports VARCHAR > Hive 0.13 supports CHAR, DECIMAL(precision, scale) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-762) LP Bug: 1392452 - Support new Hive data types such as CHAR
[ https://issues.apache.org/jira/browse/TRAFODION-762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming reassigned TRAFODION-762: -- Assignee: liu ming (was: Suresh Subbiah) > LP Bug: 1392452 - Support new Hive data types such as CHAR > -- > > Key: TRAFODION-762 > URL: https://issues.apache.org/jira/browse/TRAFODION-762 > Project: Apache Trafodion > Issue Type: Wish > Components: sql-cmp >Reporter: Hans Zeller >Assignee: liu ming >Priority: Minor > > Hive now seems to support data types that match Trafodion types very well. > According to > https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Create/Drop/TruncateTable > Hive 0.11 supports DECIMAL > Hive 0.12 supports VARCHAR > Hive 0.13 supports CHAR, DECIMAL(precision, scale) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-2002) Missing column checks when inserting into Hive table
[ https://issues.apache.org/jira/browse/TRAFODION-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289991#comment-15289991 ] ASF GitHub Bot commented on TRAFODION-2002: --- GitHub user zellerh opened a pull request: https://github.com/apache/incubator-trafodion/pull/490 TRAFODION-2002 check columns for Hive inserts Also TRAFODION-1904 column list in insert/select into Hive table is ignored Added checks for matching number and data types, so that the data to be inserted matches the column layout of the Hive target table. Using a column list for insert into a Hive table now will raise SQL error 4223 instead of being ignored (so it is still not supported). You can merge this pull request into a Git repository by running: $ git pull https://github.com/zellerh/incubator-trafodion bug/1910 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/490.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #490 commit 3205c6a2470146297ea5215a3e82eab6b74c1541 Author: Hans Zeller Date: 2016-05-18T22:25:21Z TRAFODION-2002 check columns for Hive inserts Also TRAFODION-1904 column list in insert/select into Hive table is ignored Added checks for matching number and data types, so that the data to be inserted matches the column layout of the Hive target table. Using a column list for insert into a Hive table now will raise SQL error 4223 instead of being ignored (so it is still not supported). > Missing column checks when inserting into Hive table > > > Key: TRAFODION-2002 > URL: https://issues.apache.org/jira/browse/TRAFODION-2002 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating > Environment: Any >Reporter: Hans Zeller >Assignee: Hans Zeller > Fix For: 2.1-incubating > > > Anoop found this problem: There are no checks when we insert into Hive > tables, the SELECT list could have more or fewer columns than the Hive target > table, and the types of the columns could be incompatible. Example: > -- in Hive: > drop table tph; > create table tph (a int, b int); > -- in Trafodion > insert into hive.hive.tph values (1,1,1); > select * from tph; > -- shows two columns > insert into hive.hive.tph values(1); > select * from tph; > -- those may cause a core dump -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-1904) Column list in insert into Hive table is ignored
[
https://issues.apache.org/jira/browse/TRAFODION-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TRAFODION-1904 started by Hans Zeller.
--
> Column list in insert into Hive table is ignored
>
>
> Key: TRAFODION-1904
> URL: https://issues.apache.org/jira/browse/TRAFODION-1904
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
>Affects Versions: 1.3-incubating
> Environment: Any
>Reporter: Hans Zeller
>Assignee: Hans Zeller
>
> Trafodion supports inserts into simple Hive tables. However, I noticed that
> if a column list is specified, that list is ignored. Example:
> Create this table in Hive:
> {noformat}
> create table instest(a int, b string, c int);
> {noformat}
> Then, in Trafodion:
> {noformat}
> create table inssrc(a int, b char(10), c int);
> insert into inssrc values(1,'two', 3);
> insert into hive.hive.instest(c,b,a) select a,b,c from inssrc;
> {noformat}
> Use a new sqlci session:
> {noformat}
> cqd hive_max_string_length '20';
> select * from hive.hive.instest;
> {noformat}
> This returns 1, two, 3 instead of 3, two, 1.
> Similarly, if the list is shorter than the number of columns in the Hive
> table, it fills the last columns with NULLs, not the omitted columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-2002) Missing column checks when inserting into Hive table
Hans Zeller created TRAFODION-2002: -- Summary: Missing column checks when inserting into Hive table Key: TRAFODION-2002 URL: https://issues.apache.org/jira/browse/TRAFODION-2002 Project: Apache Trafodion Issue Type: Bug Components: sql-cmp Affects Versions: 1.2-incubating Environment: Any Reporter: Hans Zeller Assignee: Hans Zeller Fix For: 2.1-incubating Anoop found this problem: There are no checks when we insert into Hive tables, the SELECT list could have more or fewer columns than the Hive target table, and the types of the columns could be incompatible. Example: -- in Hive: drop table tph; create table tph (a int, b int); -- in Trafodion insert into hive.hive.tph values (1,1,1); select * from tph; -- shows two columns insert into hive.hive.tph values(1); select * from tph; -- those may cause a core dump -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-2002) Missing column checks when inserting into Hive table
[ https://issues.apache.org/jira/browse/TRAFODION-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-2002 started by Hans Zeller. -- > Missing column checks when inserting into Hive table > > > Key: TRAFODION-2002 > URL: https://issues.apache.org/jira/browse/TRAFODION-2002 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating > Environment: Any >Reporter: Hans Zeller >Assignee: Hans Zeller > Fix For: 2.1-incubating > > > Anoop found this problem: There are no checks when we insert into Hive > tables, the SELECT list could have more or fewer columns than the Hive target > table, and the types of the columns could be incompatible. Example: > -- in Hive: > drop table tph; > create table tph (a int, b int); > -- in Trafodion > insert into hive.hive.tph values (1,1,1); > select * from tph; > -- shows two columns > insert into hive.hive.tph values(1); > select * from tph; > -- those may cause a core dump -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2001) Trafodion Elasticity enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo E Correa updated TRAFODION-2001: Attachment: TRAFODION-2001-Elasticity.docx This paper proposes changes to the Apache Trafodion Incubation configuration and operational elements used to define and operate a Trafodion cluster in a Trafodion instance. The changes proposed in this document build on existing functionality for enhancing Trafodion to support elasticity by implementing the ability to add and delete nodes used by Trafodion components > Trafodion Elasticity enhancements > - > > Key: TRAFODION-2001 > URL: https://issues.apache.org/jira/browse/TRAFODION-2001 > Project: Apache Trafodion > Issue Type: New Feature > Components: documentation, foundation, installer >Affects Versions: 2.1-incubating >Reporter: Gonzalo E Correa > Attachments: TRAFODION-2001-Elasticity.docx > > Original Estimate: 672h > Remaining Estimate: 672h > > Abstract > This JIRA proposes changes to the Apache Trafodion Incubation configuration > and operational elements used to define and operate a Trafodion cluster in a > Trafodion instance. The changes proposed build on existing functionality for > enhancing Trafodion to support elasticity by implementing the ability to add > and delete nodes used by Trafodion components. > The concept of a cluster is defined in Trafodion through the configuration of > nodes in the ‘sqconfig’ text file, the Trafodion configuration file. This > configuration file is compiled to generate a set of files used to start and > stop a Trafodion instance. The files generated consist of a configuration > database and scripts which presently contain fixed, i.e., hardcoded, > configuration topology attributes of a configured Trafodion instance. This > proposal addresses this hardcoded configuration topology issue by adding new > configuration commands in the Trafodion Foundation’s monitor components, > changing the methodology in the scripts generated, and extending the use of > the configuration database currently in use. > Objectives > The objective of this proposal is to implement elasticity capabilities in > Trafodion to match or exceed the elasticity capabilities of other modules in > the Hadoop eco system. > This focuses on the Trafodion Foundation functionality. Specifically, the > monitor components which use the configuration of nodes that define a > Trafodion cluster are enhanced to provide at set of primitive commands to add > and delete nodes as well as the generation of events to existing processes in > the instance of the addition or deletion of member nodes to the cluster > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-1904) Column list in insert into Hive table is ignored
[
https://issues.apache.org/jira/browse/TRAFODION-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hans Zeller reassigned TRAFODION-1904:
--
Assignee: Hans Zeller
> Column list in insert into Hive table is ignored
>
>
> Key: TRAFODION-1904
> URL: https://issues.apache.org/jira/browse/TRAFODION-1904
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
>Affects Versions: 1.3-incubating
> Environment: Any
>Reporter: Hans Zeller
>Assignee: Hans Zeller
>
> Trafodion supports inserts into simple Hive tables. However, I noticed that
> if a column list is specified, that list is ignored. Example:
> Create this table in Hive:
> {noformat}
> create table instest(a int, b string, c int);
> {noformat}
> Then, in Trafodion:
> {noformat}
> create table inssrc(a int, b char(10), c int);
> insert into inssrc values(1,'two', 3);
> insert into hive.hive.instest(c,b,a) select a,b,c from inssrc;
> {noformat}
> Use a new sqlci session:
> {noformat}
> cqd hive_max_string_length '20';
> select * from hive.hive.instest;
> {noformat}
> This returns 1, two, 3 instead of 3, two, 1.
> Similarly, if the list is shorter than the number of columns in the Hive
> table, it fills the last columns with NULLs, not the omitted columns.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (TRAFODION-2001) Trafodion Elasticity enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gonzalo E Correa updated TRAFODION-2001: Comment: was deleted (was: This paper proposes changes to the Apache Trafodion Incubation configuration and operational elements used to define and operate a Trafodion cluster in a Trafodion instance. The changes proposed in this document build on existing functionality for enhancing Trafodion to support elasticity by implementing the ability to add and delete nodes used by Trafodion components) > Trafodion Elasticity enhancements > - > > Key: TRAFODION-2001 > URL: https://issues.apache.org/jira/browse/TRAFODION-2001 > Project: Apache Trafodion > Issue Type: New Feature > Components: documentation, foundation, installer >Affects Versions: 2.1-incubating >Reporter: Gonzalo E Correa > Attachments: TRAFODION-2001-Elasticity.docx > > Original Estimate: 672h > Remaining Estimate: 672h > > Abstract > This JIRA proposes changes to the Apache Trafodion Incubation configuration > and operational elements used to define and operate a Trafodion cluster in a > Trafodion instance. The changes proposed build on existing functionality for > enhancing Trafodion to support elasticity by implementing the ability to add > and delete nodes used by Trafodion components. > The concept of a cluster is defined in Trafodion through the configuration of > nodes in the ‘sqconfig’ text file, the Trafodion configuration file. This > configuration file is compiled to generate a set of files used to start and > stop a Trafodion instance. The files generated consist of a configuration > database and scripts which presently contain fixed, i.e., hardcoded, > configuration topology attributes of a configured Trafodion instance. This > proposal addresses this hardcoded configuration topology issue by adding new > configuration commands in the Trafodion Foundation’s monitor components, > changing the methodology in the scripts generated, and extending the use of > the configuration database currently in use. > Objectives > The objective of this proposal is to implement elasticity capabilities in > Trafodion to match or exceed the elasticity capabilities of other modules in > the Hadoop eco system. > This focuses on the Trafodion Foundation functionality. Specifically, the > monitor components which use the configuration of nodes that define a > Trafodion cluster are enhanced to provide at set of primitive commands to add > and delete nodes as well as the generation of events to existing processes in > the instance of the addition or deletion of member nodes to the cluster > configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2001) Trafodion Elasticity enhancements
Gonzalo E Correa created TRAFODION-2001: --- Summary: Trafodion Elasticity enhancements Key: TRAFODION-2001 URL: https://issues.apache.org/jira/browse/TRAFODION-2001 Project: Apache Trafodion Issue Type: New Feature Components: documentation, foundation, installer Affects Versions: 2.1-incubating Reporter: Gonzalo E Correa Abstract This JIRA proposes changes to the Apache Trafodion Incubation configuration and operational elements used to define and operate a Trafodion cluster in a Trafodion instance. The changes proposed build on existing functionality for enhancing Trafodion to support elasticity by implementing the ability to add and delete nodes used by Trafodion components. The concept of a cluster is defined in Trafodion through the configuration of nodes in the ‘sqconfig’ text file, the Trafodion configuration file. This configuration file is compiled to generate a set of files used to start and stop a Trafodion instance. The files generated consist of a configuration database and scripts which presently contain fixed, i.e., hardcoded, configuration topology attributes of a configured Trafodion instance. This proposal addresses this hardcoded configuration topology issue by adding new configuration commands in the Trafodion Foundation’s monitor components, changing the methodology in the scripts generated, and extending the use of the configuration database currently in use. Objectives The objective of this proposal is to implement elasticity capabilities in Trafodion to match or exceed the elasticity capabilities of other modules in the Hadoop eco system. This focuses on the Trafodion Foundation functionality. Specifically, the monitor components which use the configuration of nodes that define a Trafodion cluster are enhanced to provide at set of primitive commands to add and delete nodes as well as the generation of events to existing processes in the instance of the addition or deletion of member nodes to the cluster configuration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (TRAFODION-1993) installer needs to expand DCS and REST directories
[ https://issues.apache.org/jira/browse/TRAFODION-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Varnau closed TRAFODION-1993. --- Resolution: Fixed Assignee: Amanda Moran Fix Version/s: 2.0-incubating > installer needs to expand DCS and REST directories > -- > > Key: TRAFODION-1993 > URL: https://issues.apache.org/jira/browse/TRAFODION-1993 > Project: Apache Trafodion > Issue Type: Bug > Components: installer >Affects Versions: 2.0-incubating >Reporter: Steve Varnau >Assignee: Amanda Moran > Fix For: 2.0-incubating > > > Recent packaging changes also changed calculation of DCS_INSTALL_DIR and > REST_INSTALL_DIR. The path values include * instead of the actual release > number. > The paths needs to be expanded to the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1993) installer needs to expand DCS and REST directories
[ https://issues.apache.org/jira/browse/TRAFODION-1993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289478#comment-15289478 ] Steve Varnau commented on TRAFODION-1993: - Amanda fixed this in release2.0 branch. > installer needs to expand DCS and REST directories > -- > > Key: TRAFODION-1993 > URL: https://issues.apache.org/jira/browse/TRAFODION-1993 > Project: Apache Trafodion > Issue Type: Bug > Components: installer >Affects Versions: 2.0-incubating >Reporter: Steve Varnau > Fix For: 2.0-incubating > > > Recent packaging changes also changed calculation of DCS_INSTALL_DIR and > REST_INSTALL_DIR. The path values include * instead of the actual release > number. > The paths needs to be expanded to the actual value. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1997) Unable to install Trafodion using Cloudera version 5.6
[ https://issues.apache.org/jira/browse/TRAFODION-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289476#comment-15289476 ] Steve Varnau commented on TRAFODION-1997: - Installer now checks for CDH5.4, as 5.5 and 5.6 are not supported in 2.0.0. > Unable to install Trafodion using Cloudera version 5.6 > -- > > Key: TRAFODION-1997 > URL: https://issues.apache.org/jira/browse/TRAFODION-1997 > Project: Apache Trafodion > Issue Type: Bug > Components: Build Infrastructure >Reporter: Roberta Marton > > Building Trafodion 2.0.0 using Cloudera 5.6 failed. > Source tar: > https://dist.apache.org/repos/dist/dev/incubator/trafodion/trafodion-2.0.0-RC2/apache-trafodion-2.0.0-incubating-src.tar.gz > According to the documentation, Cloudera 5.5 and 5.6 is compatible with > Trafodion; however, when trying to install Trafodion with Cloudera 5.6 failed > with the following error: > ***INFO: Cloudera installed will run traf_cloudera_mods > ***ERROR: unable to find > /usr/lib/trafodion/apache-trafodion_server-2.0.0-debug/export/lib/hbase-trx-cdh5_5-*.jar > ***ERROR: traf_cloudera_mods exited with error. > Looking at the supplied jar files, we are not creating the above file: > ls /usr/lib/trafodion/*debug/export/lib > ... > hbase-trx-cdh5_4-2.0.0.jar > We need to either: > Add support for hbase-trx-cdh5_5-*.jar OR > change the documentation and installer to only allow 5.4 versions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1998) JDBC Type2 column information improve
[ https://issues.apache.org/jira/browse/TRAFODION-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289477#comment-15289477 ] ASF GitHub Bot commented on TRAFODION-1998: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/489 > JDBC Type2 column information improve > - > > Key: TRAFODION-1998 > URL: https://issues.apache.org/jira/browse/TRAFODION-1998 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: Weiqing Xu >Priority: Trivial > > JDBC type2 use query to get the columns information from SQL. > 1. For Nullable, use the origin value from SQL > 2. For remark, return empty string since not support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1988) Better java exception handling in the java layer of Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289469#comment-15289469 ] ASF GitHub Bot commented on TRAFODION-1988: --- Github user asfgit closed the pull request at: https://github.com/apache/incubator-trafodion/pull/479 > Better java exception handling in the java layer of Trafodion > - > > Key: TRAFODION-1988 > URL: https://issues.apache.org/jira/browse/TRAFODION-1988 > Project: Apache Trafodion > Issue Type: Improvement > Components: dtm, sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Java exceptions are not handled in consistent manner in Trafodion. The SQL > interface layer in Trafodion is capable of displaying the entire java stack > trace to the client application when an exception is raised in java portion > of the Trafodion/Hbase/Hdfs stack. However, there are portions of the code in > Trafodion where the exceptions are not handled in a consistent manner. This > JIRA attempts to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1956) timeout in tdm_arkcmp process
[ https://issues.apache.org/jira/browse/TRAFODION-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289413#comment-15289413 ] ASF GitHub Bot commented on TRAFODION-1956: --- Github user selvaganesang commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/488#discussion_r63748945 --- Diff: core/sql/cli/SessionDefaults.cpp --- @@ -193,6 +194,8 @@ SessionDefaults::SessionDefaults(CollHeap * heap) setEspStopIdleTimeout(60); // Default is 1800 (idle ESPs time out in 30 minutes) setEspIdleTimeout(30*60); + // Default is 1800 (Compiler Idle time out in 30 minutes) + setCompilerIdleTimeout(30*60); --- End diff -- Yes. DDL and update statistics would start a new compiler. We could. But, I would leave it for 30 minutes for now to avoid the possibility of increasing the regression run time due to arkcmp startup assuming the regression tests wouldn't take more than 30 minutes between consequent DDL statements. > timeout in tdm_arkcmp process > - > > Key: TRAFODION-1956 > URL: https://issues.apache.org/jira/browse/TRAFODION-1956 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Affects Versions: any >Reporter: Henry Lin >Assignee: Selvaganesan Govindarajan > Labels: patch > > The tdm_arkcmp is spawned for extra sql compilation as needed, but the > tdm_arkcmp process will never stop and become an orphan process. It would be > better to introduce a mechanism to let tdm_arkcmp stop, e.g. timeout for an > idle tdm_arkcmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1956) timeout in tdm_arkcmp process
[
https://issues.apache.org/jira/browse/TRAFODION-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289404#comment-15289404
]
ASF GitHub Bot commented on TRAFODION-1956:
---
Github user selvaganesang commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/488#discussion_r63747971
--- Diff: core/sql/cli/Context.cpp ---
@@ -4943,6 +4939,27 @@ Lng32 parse_statsReq(short statsReqType,char
*statsReqStr, Lng32 statsReqStrLen,
return -1;
}
return 0;
+
+}
+
+void ContextCli::killIdleMxcmp()
+{
+ Int64 currentTimestamp = -1;
+ Int32 compilerIdleTimeout;
+ Int64 recentIpcTimestamp ;
+
+ if (arkcmpArray_.entries() == 0)
+ return;
+ if (arkcmpArray_[0]->getServer() == NULL)
+ return;
+ compilerIdleTimeout = getSessionDefaults()->getCompilerIdleTimeout();
+ if (compilerIdleTimeout == 0)
+ return;
+ if (currentTimestamp == -1)
+ currentTimestamp = NA_JulianTimestamp();
--- End diff --
Will do
> timeout in tdm_arkcmp process
> -
>
> Key: TRAFODION-1956
> URL: https://issues.apache.org/jira/browse/TRAFODION-1956
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-cmp
>Affects Versions: any
>Reporter: Henry Lin
>Assignee: Selvaganesan Govindarajan
> Labels: patch
>
> The tdm_arkcmp is spawned for extra sql compilation as needed, but the
> tdm_arkcmp process will never stop and become an orphan process. It would be
> better to introduce a mechanism to let tdm_arkcmp stop, e.g. timeout for an
> idle tdm_arkcmp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TRAFODION-1956) timeout in tdm_arkcmp process
[ https://issues.apache.org/jira/browse/TRAFODION-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289253#comment-15289253 ] ASF GitHub Bot commented on TRAFODION-1956: --- Github user DaveBirdsall commented on a diff in the pull request: https://github.com/apache/incubator-trafodion/pull/488#discussion_r63736792 --- Diff: core/sql/cli/SessionDefaults.cpp --- @@ -193,6 +194,8 @@ SessionDefaults::SessionDefaults(CollHeap * heap) setEspStopIdleTimeout(60); // Default is 1800 (idle ESPs time out in 30 minutes) setEspIdleTimeout(30*60); + // Default is 1800 (Compiler Idle time out in 30 minutes) + setCompilerIdleTimeout(30*60); --- End diff -- What do we use the compiler for now? SQL compiles are all done in the embedded compiler. I'm guessing DDL and some utilities are the only reasons we use a separate compiler. Since these operations are relatively infrequent, I wonder if we should make the timeout shorter (say, 5 minutes) since the compiler will be idle most the time. It would reduce the process and memory footprint on the system. > timeout in tdm_arkcmp process > - > > Key: TRAFODION-1956 > URL: https://issues.apache.org/jira/browse/TRAFODION-1956 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Affects Versions: any >Reporter: Henry Lin >Assignee: Selvaganesan Govindarajan > Labels: patch > > The tdm_arkcmp is spawned for extra sql compilation as needed, but the > tdm_arkcmp process will never stop and become an orphan process. It would be > better to introduce a mechanism to let tdm_arkcmp stop, e.g. timeout for an > idle tdm_arkcmp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1956) timeout in tdm_arkcmp process
[
https://issues.apache.org/jira/browse/TRAFODION-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289248#comment-15289248
]
ASF GitHub Bot commented on TRAFODION-1956:
---
Github user DaveBirdsall commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/488#discussion_r63736409
--- Diff: core/sql/cli/Context.cpp ---
@@ -4943,6 +4939,27 @@ Lng32 parse_statsReq(short statsReqType,char
*statsReqStr, Lng32 statsReqStrLen,
return -1;
}
return 0;
+
+}
+
+void ContextCli::killIdleMxcmp()
+{
+ Int64 currentTimestamp = -1;
+ Int32 compilerIdleTimeout;
+ Int64 recentIpcTimestamp ;
+
+ if (arkcmpArray_.entries() == 0)
+ return;
+ if (arkcmpArray_[0]->getServer() == NULL)
+ return;
+ compilerIdleTimeout = getSessionDefaults()->getCompilerIdleTimeout();
+ if (compilerIdleTimeout == 0)
+ return;
+ if (currentTimestamp == -1)
+ currentTimestamp = NA_JulianTimestamp();
--- End diff --
No need to test currentTimestamp == -1, as it is initialized to -1; the
'if' is always true. Why not just initialize currentTimestamp to
NA_JulianTimestamp? (Of course in the release build, the C++ compiler will
optimize this out, but perhaps we can make it easier for the human reader.)
> timeout in tdm_arkcmp process
> -
>
> Key: TRAFODION-1956
> URL: https://issues.apache.org/jira/browse/TRAFODION-1956
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-cmp
>Affects Versions: any
>Reporter: Henry Lin
>Assignee: Selvaganesan Govindarajan
> Labels: patch
>
> The tdm_arkcmp is spawned for extra sql compilation as needed, but the
> tdm_arkcmp process will never stop and become an orphan process. It would be
> better to introduce a mechanism to let tdm_arkcmp stop, e.g. timeout for an
> idle tdm_arkcmp.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-2000) trafodion is not picked up as DB__ROOT if security is enabled after install
Gao, Rui-Xian created TRAFODION-2000: Summary: trafodion is not picked up as DB__ROOT if security is enabled after install Key: TRAFODION-2000 URL: https://issues.apache.org/jira/browse/TRAFODION-2000 Project: Apache Trafodion Issue Type: Bug Components: sql-security Affects Versions: 2.1-incubating Environment: centos6.7 hbase1.0 CDH5.4.8 Reporter: Gao, Rui-Xian users for DB__ROOT and DB__ADMIN are same, both are 'trafodion', and DB__ADMIN is picked up for trafodion. SQL>showddl user db__root; REGISTER USER "TRAFODION" AS "DB__ROOT"; --- SQL operation complete. SQL>showddl user db__admin; REGISTER USER "TRAFODION" AS "DB__ADMIN"; --- SQL operation complete. SQL>values(user); (EXPR) DB__ADMIN --- 1 row(s) selected. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1914) optimize "added columns" in indexes
[ https://issues.apache.org/jira/browse/TRAFODION-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289114#comment-15289114 ] liu ming commented on TRAFODION-1914: - yes, I see. It is like 'covered index'. A new syntax should be invented. unique index cannot support this. this must be added as a new feature, yes, it makes sense. thanks, Ming > optimize "added columns" in indexes > --- > > Key: TRAFODION-1914 > URL: https://issues.apache.org/jira/browse/TRAFODION-1914 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Eric Owhadi > > the current CREATE INDEX feature will always put each column added to the > index in the clustering key. But sometimes, users just want to add columns to > the index to avoid having to probe back the primary table to fetch just one > or 2 column back. Instead copying these columns in the index can avoid making > a probe back to main table and therefore improve performance. Current > implementation allows this, but will always put the extra column as part of > the clustering key. That is not optimal, and very bad for the case of > VARCHAR, since they are exploded to there max size when part of the > clustering key. So this JIRA is abount altering the syntax of create index, > and flag columns that are added but should not be part of the clustering key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1914) optimize "added columns" in indexes
[ https://issues.apache.org/jira/browse/TRAFODION-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289108#comment-15289108 ] Eric Owhadi commented on TRAFODION-1914: Hi Ming, No it is different thing. In my JIRA, there is no limitation of it being only for unique index. Hope that makes sense, Eric > optimize "added columns" in indexes > --- > > Key: TRAFODION-1914 > URL: https://issues.apache.org/jira/browse/TRAFODION-1914 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Eric Owhadi > > the current CREATE INDEX feature will always put each column added to the > index in the clustering key. But sometimes, users just want to add columns to > the index to avoid having to probe back the primary table to fetch just one > or 2 column back. Instead copying these columns in the index can avoid making > a probe back to main table and therefore improve performance. Current > implementation allows this, but will always put the extra column as part of > the clustering key. That is not optimal, and very bad for the case of > VARCHAR, since they are exploded to there max size when part of the > clustering key. So this JIRA is abount altering the syntax of create index, > and flag columns that are added but should not be part of the clustering key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1914) optimize "added columns" in indexes
[ https://issues.apache.org/jira/browse/TRAFODION-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289076#comment-15289076 ] liu ming commented on TRAFODION-1914: - >>create table ut1 ( c1 int not null, c2 int not null, primary key (c1) ); --- SQL operation complete. >>insert into ut1 Values(1,1); --- 1 row(s) inserted. >>create unique index ui1 on ut1(c2); --- SQL operation complete. >>exit then use hbase shell hbase(main):002:0> scan 'TRAFODION.SEABASE.UI1' ROWCOLUMN+CELL \x80\x00\x00\x01 column=#1:\x01, timestamp=1463582407513, value=\x08\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00 1 row(s) in 0.0800 seconds > optimize "added columns" in indexes > --- > > Key: TRAFODION-1914 > URL: https://issues.apache.org/jira/browse/TRAFODION-1914 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Eric Owhadi > > the current CREATE INDEX feature will always put each column added to the > index in the clustering key. But sometimes, users just want to add columns to > the index to avoid having to probe back the primary table to fetch just one > or 2 column back. Instead copying these columns in the index can avoid making > a probe back to main table and therefore improve performance. Current > implementation allows this, but will always put the extra column as part of > the clustering key. That is not optimal, and very bad for the case of > VARCHAR, since they are exploded to there max size when part of the > clustering key. So this JIRA is abount altering the syntax of create index, > and flag columns that are added but should not be part of the clustering key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1914) optimize "added columns" in indexes
[ https://issues.apache.org/jira/browse/TRAFODION-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289075#comment-15289075 ] liu ming commented on TRAFODION-1914: - Hi, Eric, I filed JIRA 1976 Trafodion support to create 'unique index'. In that case, one should make sure the index column value will be unique. Then that index will not have primary key list into clustering key. This is already supported but not documented. So this seems like a solved issue? > optimize "added columns" in indexes > --- > > Key: TRAFODION-1914 > URL: https://issues.apache.org/jira/browse/TRAFODION-1914 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Eric Owhadi > > the current CREATE INDEX feature will always put each column added to the > index in the clustering key. But sometimes, users just want to add columns to > the index to avoid having to probe back the primary table to fetch just one > or 2 column back. Instead copying these columns in the index can avoid making > a probe back to main table and therefore improve performance. Current > implementation allows this, but will always put the extra column as part of > the clustering key. That is not optimal, and very bad for the case of > VARCHAR, since they are exploded to there max size when part of the > clustering key. So this JIRA is abount altering the syntax of create index, > and flag columns that are added but should not be part of the clustering key. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1632) Hive scan on wide tables with several string type columns causes SIGSEGV
[ https://issues.apache.org/jira/browse/TRAFODION-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289052#comment-15289052 ] liu ming commented on TRAFODION-1632: - create table Input_10_TestClientData ( sourcehistoryuid bigint ,importdate timestamp ,filedate timestamp ,exclusionindicator tinyint ,DataCategory STRING ,TransactionReferenceNumber STRING ,ReportStatus STRING ,ReporterIDType STRING ,ReporterID STRING ,SubmitterIDType STRING ,SubmitterID STRING ,Buyer_ID_Type STRING ,Buyer_ID STRING ,BuyerCountryofBranch STRING ,BuyerFirstName STRING ,BuyerSurname STRING ,BuyerDOB STRING ,BuyerCountryofResidence STRING ,BuyerPostCode STRING ,BuyerDecisionMakerIDType STRING ,BuyerDecisionMakerID STRING ,BuyerDecisionMakerFirstName STRING ,BuyerDecisionMakerSurname STRING ,BuyerDecisionMakerDOB STRING ,BuyerDecisionMakerCountryofResidence STRING ,BuyerDecisionMakerPostCode STRING ,SellerIDType STRING ,SellerID STRING ,SellerCountryofBranch STRING ,SellerFirstName STRING ,SellerSurname STRING ,SellerDOB STRING ,SellerCountryofResidence STRING ,SellerPostCode STRING ,SellerDecisionMakerIDType STRING ,SellerDecisionMakerID STRING ,SellerDecisionMakerFirstName STRING ,SellerDecisionMakerSurname STRING ,SellerDecisionMakerDOB STRING ,SellerDecisionMakerCountryofResidence STRING ,SellerDecisionMakerPostCode STRING ,OrderTransmissionIndicator STRING ,BuyerTransmitterIDType STRING ,BuyerTransmitterID STRING ,SellerTransmitterIDType STRING ,SellerTransmitterID STRING ,TradingDate STRING ,TradingTime STRING ,TradingCapacity STRING ,Quantity STRING ,QuantityNotation STRING ,Price STRING ,PriceNotation STRING ,Currency1 STRING ,Currency2 STRING ,PriceMultiplier STRING ,Consideration STRING ,Venue STRING ,ExecutingCountryofBranch STRING ,InstrumentIDType STRING ,InstrumentID STRING ,InstrumentClassificationType STRING ,InstrumentClassification STRING ,UnderlyingInstrumentIDType STRING ,UnderlyingInstrumentID STRING ,PutCall STRING ,StrikePrice STRING ,OptionStyle STRING ,MaturityDate STRING ,ResultofExercise STRING ,DeliveryType STRING ,UpFrontPayment STRING ,UpFrontPaymentCurrency STRING ,ContractModificationType STRING ,InvestmentTraderIDType STRING ,InvestmentTraderID STRING ,InvestmentTraderCountryofBranch STRING ,ExecutionTraderIDType STRING ,ExecutionTraderID STRING ,ExecutionTraderCountryofBranch STRING ,InvestmentAlgorithmID STRING ,ExecutionAlgorithmID STRING ,WaiverIndicator STRING ,ShortSellingIndicator STRING ,OTCPostTradeIndicator STRING ,CommodityDerivativeIndicator STRING ,ReloadSourceHistoryUID STRING ) ; will pass Hive syntax checking > Hive scan on wide tables with several string type columns causes SIGSEGV > - > > Key: TRAFODION-1632 > URL: https://issues.apache.org/jira/browse/TRAFODION-1632 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 1.3-incubating >Reporter: Suresh Subbiah > Attachments: hs_err_pid54160.log > > > This query caused a process abort. > select * from hive.hive."Input_10_TestClientData_1" limit 10; > Table has 88 columns and 100K rows > Hive DDL is > create table "Input_10_TestClientData" ( > ,"sourcehistoryuid" bigint > ,"importdate" timestamp > ,"filedate" timestamp > ,"exclusionindicator" tinyint > ,"Data Category" STRING > ,"Transaction Reference Number" STRING > ,"Report Status" STRING > ,"Reporter ID Type" STRING > ,"Reporter ID" STRING > ,"Submitter ID Type" STRING > ,"Submitter ID" STRING > ,"Buyer ID Type" STRING > ,"Buyer ID" STRING > ,"Buyer Country of Branch" STRING > ,"Buyer First Name" STRING > ,"Buyer Surname" STRING > ,"Buyer DOB" STRING > ,"Buyer Country of Residence" STRING > ,"Buyer Post Code" STRING > ,"Buyer Decision Maker ID Type" STRING > ,"Buyer Decision Maker ID" STRING > ,"Buyer Decision Maker First Name" STRING > ,"Buyer Decision Maker Surname" STRING > ,"Buyer Decision Maker DOB" STRING > ,"Buyer Decision Maker Country of Residence" STRING > ,"Buyer Decision Maker Post Code" STRING > ,"Seller ID Type" STRING > ,"Seller ID" STRING > ,"Seller Country of Branch" STRING > ,"Seller First Name" STRING > ,"Seller Surname" STRING > ,"Seller DOB" STRING > ,"Seller Country of Residence" STRING > ,"Seller Post Code" STRING > ,"Seller Decision Maker ID Type" STRING > ,"Seller Decision Maker ID" STRING > ,"Seller Decision Maker First Name" STRING > ,"Seller Decision Maker Surname" STRING > ,"Seller Decision Maker DOB" STRING > ,"Seller Decision Maker Country of Residence" STRING > ,"Seller Decision Maker Post Code" STRING > ,"Order Trans
[jira] [Commented] (TRAFODION-209) LP Bug: 1298673 - Monitor expects node names to have characters that are only lowercase
[ https://issues.apache.org/jira/browse/TRAFODION-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15289010#comment-15289010 ] liu ming commented on TRAFODION-209: solved by TRAFODION-1854 > LP Bug: 1298673 - Monitor expects node names to have characters that are only > lowercase > --- > > Key: TRAFODION-209 > URL: https://issues.apache.org/jira/browse/TRAFODION-209 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Reporter: Joanie Cooper >Assignee: liu ming > Fix For: 2.0-incubating > > > You can create node names for example "Joanie-vm-1" in the HP Cloud. When > you install trafodion, the appropriate "sqconfig" and "cluster.conf" file > entries correctly indicate the node name "Joanie-vm-1". However, when the > monitor is launched, internally, it has shifted the name to be all lowercase, > e.g. "joanie-vm-1". This causes the monitor initialization to fail and > trafodion can not start. There are no monitor core files generated. This > was analyzed via "gdb" as the monitor process was initializing. The > workaround is to specify that all node names must use lowercase characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-209) LP Bug: 1298673 - Monitor expects node names to have characters that are only lowercase
[ https://issues.apache.org/jira/browse/TRAFODION-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming resolved TRAFODION-209. Resolution: Fixed > LP Bug: 1298673 - Monitor expects node names to have characters that are only > lowercase > --- > > Key: TRAFODION-209 > URL: https://issues.apache.org/jira/browse/TRAFODION-209 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Reporter: Joanie Cooper >Assignee: liu ming > Fix For: 2.0-incubating > > > You can create node names for example "Joanie-vm-1" in the HP Cloud. When > you install trafodion, the appropriate "sqconfig" and "cluster.conf" file > entries correctly indicate the node name "Joanie-vm-1". However, when the > monitor is launched, internally, it has shifted the name to be all lowercase, > e.g. "joanie-vm-1". This causes the monitor initialization to fail and > trafodion can not start. There are no monitor core files generated. This > was analyzed via "gdb" as the monitor process was initializing. The > workaround is to specify that all node names must use lowercase characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-209) LP Bug: 1298673 - Monitor expects node names to have characters that are only lowercase
[ https://issues.apache.org/jira/browse/TRAFODION-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming reassigned TRAFODION-209: -- Assignee: liu ming (was: Atanu Mishra) > LP Bug: 1298673 - Monitor expects node names to have characters that are only > lowercase > --- > > Key: TRAFODION-209 > URL: https://issues.apache.org/jira/browse/TRAFODION-209 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Reporter: Joanie Cooper >Assignee: liu ming > Fix For: 2.0-incubating > > > You can create node names for example "Joanie-vm-1" in the HP Cloud. When > you install trafodion, the appropriate "sqconfig" and "cluster.conf" file > entries correctly indicate the node name "Joanie-vm-1". However, when the > monitor is launched, internally, it has shifted the name to be all lowercase, > e.g. "joanie-vm-1". This causes the monitor initialization to fail and > trafodion can not start. There are no monitor core files generated. This > was analyzed via "gdb" as the monitor process was initializing. The > workaround is to specify that all node names must use lowercase characters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-1999) trafodion init failed, have to remove /trafodion znode to continue
liu ming created TRAFODION-1999: --- Summary: trafodion init failed, have to remove /trafodion znode to continue Key: TRAFODION-1999 URL: https://issues.apache.org/jira/browse/TRAFODION-1999 Project: Apache Trafodion Issue Type: Bug Reporter: liu ming Error during initialize trafodion. Error msg in log file shows: 2016-05-18 08:44:18,876, INFO, MON, Node Number: 0,, PIN: 23596 , Process Name: $MONITOR,,, TID: 23599, Message ID: 101130801, STDERR redirected from test01.$TM0.0.23982: at org.apache.hadoop.hbase.client.HBaseAdmin$5.call(HBaseAdmin.java:661) at org.apache.hadoop.hbase.client.HBaseAdmin$5.call(HBaseAdmin.java:657) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:126) ... 6 more Exception in thread "main" java.lang.RuntimeException: org.apache.hadoop.hbase.TableExistsException: org.apache.hadoop.hbase.TableExistsException: TRAFODION._DTM_.TDDL at org.apache.hadoop.hbase.master.handler.CreateTableHandler.checkAndSetEnablingTable(CreateTableHandler.java:161) at org.apache.hadoop.hbase.master.handler.CreateTableHandler.prepare(CreateTableHandler.java:129) at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1279) at org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:399) at org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436) at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2033) at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) at java.lang.Thread.run(Thread.java:745) at org.trafodion.dtm.HBaseTxClient.init(HBaseTxClient.java:244) Caused by: org.apache.hadoop.hbase.TableExistsException: org.apache.hadoop.hbase.TableExistsException: TRAFODION._DTM_.TDDL at org.apache.hadoop.hbase.master.handler.CreateTableHandler.checkAndSetEnablingTable(CreateTableHandler.java:161) at org.apache.hadoop.hbase.master.handler.CreateTableHandler.prepare(CreateTableHandler.java:129) at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1279) at org.apache.hadoop.hbase.master.MasterRpcServices.createTable(MasterRpcServices.java:399) at org.apache.hadoop.hbase.protobuf.generated.MasterProtos$MasterService$2.callBlockingMethod(MasterProtos.java:42436) at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2033) at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) at java.lang.Thread.run(Thread.java:745) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106) at org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:95) at org.apache.hadoop.hbase.client.RpcRetryingCaller.translateException(RpcRetryingCaller.java:226) at org.apache.hadoop.hbase.client.RpcRetryingCaller.translateException(RpcRetryingCaller.java:240) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:140) at org.apache.hadoop.hbase.client.HBaseAdmin.executeCallable(HBaseAdmin.java:3601) at org.apache.hadoop.hbase.client.HBaseAdmin.createTableAsync(HBaseAdmin.java:657) at org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:539) at org.apache.hadoop.hbase.client.HBaseAdmin.createTable(HBaseAdmin.java:471) at org.apache.hadoop.hbase.client.transactional.TmDDL.(TmDDL.java:93) at org.trafodion.dtm.HBaseTxClient.init(HBaseTxClient.java:239) Caused by: org.apache.hadoop.hbase.ipc.RemoteWithExtrasException(org.apache.hadoop.hbase.TableExistsException): org.apache.hadoop.hbase.TableExistsException: TRAFODION._DTM_.TDDL at org.apache.hadoop.hbase.master.handler.CreateTableHandler.checkAndSetEnablingTable(CreateTableHandler.java:161) at org.apache.hadoop.hbase.master.handler.CreateTableHandler.prepare(CreateTableHandler.java:129) at org.apache.hadoop.hbase.master.HMaster.createTable(HMaster.java:1279) at org.apache.ha2016-05-1
[jira] [Updated] (TRAFODION-1108) LP Bug: 1438467 - dtmci should return "status trans" output in JSON format
[ https://issues.apache.org/jira/browse/TRAFODION-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming updated TRAFODION-1108: Fix Version/s: (was: 2.0-incubating) > LP Bug: 1438467 - dtmci should return "status trans" output in JSON format > -- > > Key: TRAFODION-1108 > URL: https://issues.apache.org/jira/browse/TRAFODION-1108 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Reporter: Joanie Cooper >Assignee: liu ming >Priority: Critical > Fix For: 2.1-incubating > > > To support the HPDSM team, the "dtmci" tooling should return the "status > trans" command output in JSON format. > This will be needed for the Trafodion R1.2 release. > Assigned to LaunchPad User Adriana Fuentes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-1108) LP Bug: 1438467 - dtmci should return "status trans" output in JSON format
[ https://issues.apache.org/jira/browse/TRAFODION-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming updated TRAFODION-1108: Fix Version/s: 2.1-incubating > LP Bug: 1438467 - dtmci should return "status trans" output in JSON format > -- > > Key: TRAFODION-1108 > URL: https://issues.apache.org/jira/browse/TRAFODION-1108 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Reporter: Joanie Cooper >Assignee: liu ming >Priority: Critical > Fix For: 2.0-incubating, 2.1-incubating > > > To support the HPDSM team, the "dtmci" tooling should return the "status > trans" command output in JSON format. > This will be needed for the Trafodion R1.2 release. > Assigned to LaunchPad User Adriana Fuentes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-1108) LP Bug: 1438467 - dtmci should return "status trans" output in JSON format
[ https://issues.apache.org/jira/browse/TRAFODION-1108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming reassigned TRAFODION-1108: --- Assignee: liu ming (was: Atanu Mishra) > LP Bug: 1438467 - dtmci should return "status trans" output in JSON format > -- > > Key: TRAFODION-1108 > URL: https://issues.apache.org/jira/browse/TRAFODION-1108 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Reporter: Joanie Cooper >Assignee: liu ming >Priority: Critical > Fix For: 2.0-incubating > > > To support the HPDSM team, the "dtmci" tooling should return the "status > trans" command output in JSON format. > This will be needed for the Trafodion R1.2 release. > Assigned to LaunchPad User Adriana Fuentes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-1564) Region split/balance is not being delayed if Trx Scanner obj is present
[ https://issues.apache.org/jira/browse/TRAFODION-1564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] liu ming reassigned TRAFODION-1564: --- Assignee: liu ming > Region split/balance is not being delayed if Trx Scanner obj is present > --- > > Key: TRAFODION-1564 > URL: https://issues.apache.org/jira/browse/TRAFODION-1564 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Reporter: Oliver Bucaojit >Assignee: liu ming > > A region move/split/rebalance should be delayed when a TransactionalScanner > is present on the region coprocessor 'scanners' list. The delay is not > happening and is throwing the following error: > *** ERROR[8448] Unable to access Hbase interface. Call to > ExpHbaseInterface::nextRow returned error HBASE_ACCESS_ERROR(-706). Cause: > java.util.concurrent.ExecutionException: java.io.IOException: PerformScan > error on coprocessor call, scannerID: 0 java.io.IOException: performScan > encountered Exception txID: 562962838798562 Exception: > org.apache.hadoop.hbase.UnknownScannerException: ScannerId: 0, already closed? > While debugging I noticed that in the SplitBalanceHelper the code is waiting > for clear scanners list && pending txn list. It should be '||' instead. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1998) JDBC Type2 column information improve
[ https://issues.apache.org/jira/browse/TRAFODION-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15288672#comment-15288672 ] ASF GitHub Bot commented on TRAFODION-1998: --- GitHub user xwq opened a pull request: https://github.com/apache/incubator-trafodion/pull/489 [TRAFODION-1998]JDBC Type2 column information improve JDBC type2 use query to get the columns information from SQL. 1. For Nullable, use the origin value from SQL 2. For remark, return empty string since not support You can merge this pull request into a Git repository by running: $ git pull https://github.com/xwq/incubator-trafodion master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/489.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #489 commit ec8d93159e7f80462275094fe8bad9e0897c34b7 Author: Weiqing Xu Date: 2016-05-18T09:23:49Z [TRAFODION-1998]JDBC Type2 column information improve JDBC type2 use query to get the columns information from SQL. 1. For Nullable, use the origin value from SQL 2. For remark, return empty string since not support > JDBC Type2 column information improve > - > > Key: TRAFODION-1998 > URL: https://issues.apache.org/jira/browse/TRAFODION-1998 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: Weiqing Xu >Priority: Trivial > > JDBC type2 use query to get the columns information from SQL. > 1. For Nullable, use the origin value from SQL > 2. For remark, return empty string since not support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-1998) JDBC Type2 column information improve
Weiqing Xu created TRAFODION-1998: - Summary: JDBC Type2 column information improve Key: TRAFODION-1998 URL: https://issues.apache.org/jira/browse/TRAFODION-1998 Project: Apache Trafodion Issue Type: Improvement Components: client-jdbc-t2 Reporter: Weiqing Xu Priority: Trivial JDBC type2 use query to get the columns information from SQL. 1. For Nullable, use the origin value from SQL 2. For remark, return empty string since not support -- This message was sent by Atlassian JIRA (v6.3.4#6332)
