[jira] [Commented] (TRAFODION-1812) cleanup schema causes transaction to hang in aborting state

2016-02-05 Thread Roberta Marton (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134337#comment-15134337
 ] 

Roberta Marton commented on TRAFODION-1812:
---

I am testing a fix for this right now, do you also have a fix?

 Roberta



> cleanup schema causes transaction to hang in aborting state
> ---
>
> Key: TRAFODION-1812
> URL: https://issues.apache.org/jira/browse/TRAFODION-1812
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmu
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> If a cleanup schema command is executed and the schema contains histogram 
> tables, the operation "succeeds" (but not really). One of the transactions 
> performing the cleanup commands is left in the aborting state, for example:
> (1,0,13)0,12159   281474976710669 ABORTING PT2 
> willRollback tmAborted readOnly
> Test case:
> create schema sch1;
> set schema sch1;
> create table t1(a int not null primary key);
> create table t2 (a int not null primary key,
>   b int not null unique,
>   c int not null references t1(a),
>   d blob,
>   e char(2) check (e > 'a'),
>   f largeint generated by default as identity not 
> null);
> create index t2 on t2(b);
> insert into t1 values (1), (2), (3), (4), (5), (6), (7), (8);
> update statistics for table t1 on every column;
> get tables;
> cleanup schema sch1;
> get tables;
> get schemas;
> After recovering from the transaction issue (restarting Trafodion), the 
> following objects still exist in hbase:
> TRAFODION.SCH1.SB_HISTOGRAM_INTERVALS 
>  
> TRAFODION.SCH1.T1 
>  
> TRAFODION.SCH1.T2 
>  
> TRAFODION.SCH1.T2_651147319_7148  
>  
> TRAFODION.SCH1.T2_945247319_7148  
> After removing objects from hbase, restarted sqlci:
> get schemas - schema sch1 does not exist.
> create schema sch1 - succeeded
> create table t1 - succeeded 
> create table t2 - failed *** ERROR[1390] Object TRAFODION.SEABASE.T2 already 
> exists in Trafodion.
> Table t2 is accessible - so metadata entries were not removed.
> Looking a bit into the cleanup code - part of removing an object, tries to 
> delete rows from the histograms table.  So if we are removing a histogram 
> table, probably should not be deleting from it at the same time.  May also 
> want to wait until all the other tables in the schema are removed before 
> delete histogram tables (or delete the histogram tables first).
> Prototyped a change that:
> As part of cleanup schema, cleaned up all the non histogram tables first then 
> cleaned up the histogram tables.
> As part of dropping a histogram table, did not call dropSeabaseStats.
> This seemed to fix the problem.
> May want to handle failures from delete histogram rows better. Also, if 
> someone tries to cleanup one histogram table, perhaps all should be dropped.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Work started] (TRAFODION-1793) GET commands that report usage information should return 3 or 2 part ansi object names

2016-02-05 Thread Anoop Sharma (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TRAFODION-1793 started by Anoop Sharma.
---
> GET commands that report usage information should return 3 or 2 part ansi 
> object names
> --
>
> Key: TRAFODION-1793
> URL: https://issues.apache.org/jira/browse/TRAFODION-1793
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Venkat Muthuswamy
>Assignee: Anoop Sharma
>
> Let's see we create a view that joins 2 tables from different schemas.
> CREATE VIEW TRAFODION.SCH.V1 AS
>   SELECT 1 AS Z FROM TRAFODION.SCH.T, TRAFODION.SEABASE.T ;
> Now if we try to get the tables used by V1 using this command, it just 
> returns the object names and it is difficult to say which object is which 
> since the schema information is missing.
> get tables in view v1;
> It returns :
> >>get tables in view v1;
> Tables in View SCH.V1
> =
> T
> T
> It would be good if the GET commands can return the 3 or 2 part ansi name of 
> the object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1614) Improve performance of traf_tools_setup.sh script

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134442#comment-15134442
 ] 

ASF GitHub Bot commented on TRAFODION-1614:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/306


> Improve performance of traf_tools_setup.sh script
> -
>
> Key: TRAFODION-1614
> URL: https://issues.apache.org/jira/browse/TRAFODION-1614
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: Build Infrastructure
>Reporter: Roberta Marton
>Assignee: Steve Varnau
>
> Trafodion requires several tools to be created in order to successfully 
> build.  
> Today, it takes 45 minutes to an hour on a VM to perform this task. 
> This JIRA was written to improve the time it takes to build these tools.  
> There could be several solutions to do this:
> - build tools in parallel
> - use predefined binaries, if they exists (e.g. LLVM), to avoid building them
> - release convenience binaries that contain the pre-built tools



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (TRAFODION-1793) GET commands that report usage information should return 3 or 2 part ansi object names

2016-02-05 Thread Anoop Sharma (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sharma reassigned TRAFODION-1793:
---

Assignee: Anoop Sharma

> GET commands that report usage information should return 3 or 2 part ansi 
> object names
> --
>
> Key: TRAFODION-1793
> URL: https://issues.apache.org/jira/browse/TRAFODION-1793
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Venkat Muthuswamy
>Assignee: Anoop Sharma
>
> Let's see we create a view that joins 2 tables from different schemas.
> CREATE VIEW TRAFODION.SCH.V1 AS
>   SELECT 1 AS Z FROM TRAFODION.SCH.T, TRAFODION.SEABASE.T ;
> Now if we try to get the tables used by V1 using this command, it just 
> returns the object names and it is difficult to say which object is which 
> since the schema information is missing.
> get tables in view v1;
> It returns :
> >>get tables in view v1;
> Tables in View SCH.V1
> =
> T
> T
> It would be good if the GET commands can return the 3 or 2 part ansi name of 
> the object.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1733) Incorrect information exists in LICENSE.txt file

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134499#comment-15134499
 ] 

ASF GitHub Bot commented on TRAFODION-1733:
---

Github user robertamarton commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/307#discussion_r52044608
  
--- Diff: LICENSE ---
@@ -307,11 +286,6 @@ For details see http://jquery.org/license
 
--- End diff --

Do you need to change this to point to the license file you copied to 
licenses directory?


> Incorrect information exists in LICENSE.txt file
> 
>
> Key: TRAFODION-1733
> URL: https://issues.apache.org/jira/browse/TRAFODION-1733
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Roberta Marton
>Assignee: Steve Varnau
>Priority: Minor
>
> The LICENSE.txt file contains two items that are not needed:
> An Apache license attributed to Facebook.
> A reference to asciidocs which is not part of the project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1733) Incorrect information exists in LICENSE.txt file

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134512#comment-15134512
 ] 

ASF GitHub Bot commented on TRAFODION-1733:
---

Github user robertamarton commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/307#discussion_r52045423
  
--- Diff: LICENSE ---
@@ -307,11 +286,6 @@ For details see http://jquery.org/license
 
 ++
 
-Apache Trafodion uses asciidocs to create its documentation which is 
licensed
-under MIT 
-
-For details see http://asciidoctor.org/
--- End diff --

Just to confirm - an original comment we received for our first release 
attempt (that did include docs) was that we needed to add asciidocs to our 
license file.  When we released 1.3.0, we did not include docs so we then 
received a comment that this text was not needed.  Are we going to include docs 
in our source tree?  If so, will we need this text?   


> Incorrect information exists in LICENSE.txt file
> 
>
> Key: TRAFODION-1733
> URL: https://issues.apache.org/jira/browse/TRAFODION-1733
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Roberta Marton
>Assignee: Steve Varnau
>Priority: Minor
>
> The LICENSE.txt file contains two items that are not needed:
> An Apache license attributed to Facebook.
> A reference to asciidocs which is not part of the project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (TRAFODION-1614) Improve performance of traf_tools_setup.sh script

2016-02-05 Thread Steve Varnau (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Varnau closed TRAFODION-1614.
---
   Resolution: Fixed
Fix Version/s: 2.0-incubating

> Improve performance of traf_tools_setup.sh script
> -
>
> Key: TRAFODION-1614
> URL: https://issues.apache.org/jira/browse/TRAFODION-1614
> Project: Apache Trafodion
>  Issue Type: Improvement
>  Components: Build Infrastructure
>Reporter: Roberta Marton
>Assignee: Steve Varnau
> Fix For: 2.0-incubating
>
>
> Trafodion requires several tools to be created in order to successfully 
> build.  
> Today, it takes 45 minutes to an hour on a VM to perform this task. 
> This JIRA was written to improve the time it takes to build these tools.  
> There could be several solutions to do this:
> - build tools in parallel
> - use predefined binaries, if they exists (e.g. LLVM), to avoid building them
> - release convenience binaries that contain the pre-built tools



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1733) Incorrect information exists in LICENSE.txt file

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134830#comment-15134830
 ] 

ASF GitHub Bot commented on TRAFODION-1733:
---

Github user svarnau commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/307#discussion_r52063453
  
--- Diff: LICENSE ---
@@ -307,11 +286,6 @@ For details see http://jquery.org/license
 
 ++
 
-Apache Trafodion uses asciidocs to create its documentation which is 
licensed
-under MIT 
-
-For details see http://asciidoctor.org/
--- End diff --

No, I don't think so. The docs do not include any ASCIIdoc software. It is 
merely used as a build tool to generate other formats (html, pdf) from asciidoc 
formatted files.


> Incorrect information exists in LICENSE.txt file
> 
>
> Key: TRAFODION-1733
> URL: https://issues.apache.org/jira/browse/TRAFODION-1733
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Roberta Marton
>Assignee: Steve Varnau
>Priority: Minor
>
> The LICENSE.txt file contains two items that are not needed:
> An Apache license attributed to Facebook.
> A reference to asciidocs which is not part of the project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1733) Incorrect information exists in LICENSE.txt file

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134823#comment-15134823
 ] 

ASF GitHub Bot commented on TRAFODION-1733:
---

Github user svarnau commented on a diff in the pull request:

https://github.com/apache/incubator-trafodion/pull/307#discussion_r52062989
  
--- Diff: LICENSE ---
@@ -307,11 +286,6 @@ For details see http://jquery.org/license
 
--- End diff --

Agreed. I'll fix that oversight.


> Incorrect information exists in LICENSE.txt file
> 
>
> Key: TRAFODION-1733
> URL: https://issues.apache.org/jira/browse/TRAFODION-1733
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Roberta Marton
>Assignee: Steve Varnau
>Priority: Minor
>
> The LICENSE.txt file contains two items that are not needed:
> An Apache license attributed to Facebook.
> A reference to asciidocs which is not part of the project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1813) add commons-httpclient depenedency into dcs/pom.xml

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133897#comment-15133897
 ] 

ASF GitHub Bot commented on TRAFODION-1813:
---

GitHub user traflm opened a pull request:

https://github.com/apache/incubator-trafodion/pull/308

TRAFODION-1813  add commons-httpclient depenedency into dcs/pom.xml



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/traflm/incubator-trafodion TRAFODION-1720

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/308.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 #308


commit a5eeca0cfe1bf3861c68084c2077d1cfae2e0fe5
Author: Liu Ming 
Date:   2016-02-05T09:17:03Z

TRAFODION-1813  add commons-httpclient depenedency into dcs/pom.xml




> add commons-httpclient depenedency into dcs/pom.xml
> ---
>
> Key: TRAFODION-1813
> URL: https://issues.apache.org/jira/browse/TRAFODION-1813
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: liu ming
>Assignee: liu ming
>Priority: Minor
>
> Not sure why the dependency of httpclient is missing from pom.xml under dcs 
> folder, it doesn't affect build in most cases, but I cannot make a build on a 
> fresh machine, so suggest to explicit add this dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (TRAFODION-1812) cleanup schema causes transaction to hang in aborting state

2016-02-05 Thread liu ming (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

liu ming reassigned TRAFODION-1812:
---

Assignee: liu ming  (was: Roberta Marton)

> cleanup schema causes transaction to hang in aborting state
> ---
>
> Key: TRAFODION-1812
> URL: https://issues.apache.org/jira/browse/TRAFODION-1812
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmu
>Reporter: Roberta Marton
>Assignee: liu ming
>
> If a cleanup schema command is executed and the schema contains histogram 
> tables, the operation "succeeds" (but not really). One of the transactions 
> performing the cleanup commands is left in the aborting state, for example:
> (1,0,13)0,12159   281474976710669 ABORTING PT2 
> willRollback tmAborted readOnly
> Test case:
> create schema sch1;
> set schema sch1;
> create table t1(a int not null primary key);
> create table t2 (a int not null primary key,
>   b int not null unique,
>   c int not null references t1(a),
>   d blob,
>   e char(2) check (e > 'a'),
>   f largeint generated by default as identity not 
> null);
> create index t2 on t2(b);
> insert into t1 values (1), (2), (3), (4), (5), (6), (7), (8);
> update statistics for table t1 on every column;
> get tables;
> cleanup schema sch1;
> get tables;
> get schemas;
> After recovering from the transaction issue (restarting Trafodion), the 
> following objects still exist in hbase:
> TRAFODION.SCH1.SB_HISTOGRAM_INTERVALS 
>  
> TRAFODION.SCH1.T1 
>  
> TRAFODION.SCH1.T2 
>  
> TRAFODION.SCH1.T2_651147319_7148  
>  
> TRAFODION.SCH1.T2_945247319_7148  
> After removing objects from hbase, restarted sqlci:
> get schemas - schema sch1 does not exist.
> create schema sch1 - succeeded
> create table t1 - succeeded 
> create table t2 - failed *** ERROR[1390] Object TRAFODION.SEABASE.T2 already 
> exists in Trafodion.
> Table t2 is accessible - so metadata entries were not removed.
> Looking a bit into the cleanup code - part of removing an object, tries to 
> delete rows from the histograms table.  So if we are removing a histogram 
> table, probably should not be deleting from it at the same time.  May also 
> want to wait until all the other tables in the schema are removed before 
> delete histogram tables (or delete the histogram tables first).
> Prototyped a change that:
> As part of cleanup schema, cleaned up all the non histogram tables first then 
> cleaned up the histogram tables.
> As part of dropping a histogram table, did not call dropSeabaseStats.
> This seemed to fix the problem.
> May want to handle failures from delete histogram rows better. Also, if 
> someone tries to cleanup one histogram table, perhaps all should be dropped.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (TRAFODION-1813) add commons-httpclient depenedency into dcs/pom.xml

2016-02-05 Thread liu ming (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

liu ming reassigned TRAFODION-1813:
---

Assignee: liu ming

> add commons-httpclient depenedency into dcs/pom.xml
> ---
>
> Key: TRAFODION-1813
> URL: https://issues.apache.org/jira/browse/TRAFODION-1813
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: liu ming
>Assignee: liu ming
>Priority: Minor
>
> Not sure why the dependency of httpclient is missing from pom.xml under dcs 
> folder, it doesn't affect build in most cases, but I cannot make a build on a 
> fresh machine, so suggest to explicit add this dependency.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-1812) cleanup schema causes transaction to hang in aborting state

2016-02-05 Thread liu ming (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

liu ming updated TRAFODION-1812:

Assignee: Roberta Marton  (was: liu ming)

> cleanup schema causes transaction to hang in aborting state
> ---
>
> Key: TRAFODION-1812
> URL: https://issues.apache.org/jira/browse/TRAFODION-1812
> Project: Apache Trafodion
>  Issue Type: Bug
>  Components: sql-cmu
>Reporter: Roberta Marton
>Assignee: Roberta Marton
>
> If a cleanup schema command is executed and the schema contains histogram 
> tables, the operation "succeeds" (but not really). One of the transactions 
> performing the cleanup commands is left in the aborting state, for example:
> (1,0,13)0,12159   281474976710669 ABORTING PT2 
> willRollback tmAborted readOnly
> Test case:
> create schema sch1;
> set schema sch1;
> create table t1(a int not null primary key);
> create table t2 (a int not null primary key,
>   b int not null unique,
>   c int not null references t1(a),
>   d blob,
>   e char(2) check (e > 'a'),
>   f largeint generated by default as identity not 
> null);
> create index t2 on t2(b);
> insert into t1 values (1), (2), (3), (4), (5), (6), (7), (8);
> update statistics for table t1 on every column;
> get tables;
> cleanup schema sch1;
> get tables;
> get schemas;
> After recovering from the transaction issue (restarting Trafodion), the 
> following objects still exist in hbase:
> TRAFODION.SCH1.SB_HISTOGRAM_INTERVALS 
>  
> TRAFODION.SCH1.T1 
>  
> TRAFODION.SCH1.T2 
>  
> TRAFODION.SCH1.T2_651147319_7148  
>  
> TRAFODION.SCH1.T2_945247319_7148  
> After removing objects from hbase, restarted sqlci:
> get schemas - schema sch1 does not exist.
> create schema sch1 - succeeded
> create table t1 - succeeded 
> create table t2 - failed *** ERROR[1390] Object TRAFODION.SEABASE.T2 already 
> exists in Trafodion.
> Table t2 is accessible - so metadata entries were not removed.
> Looking a bit into the cleanup code - part of removing an object, tries to 
> delete rows from the histograms table.  So if we are removing a histogram 
> table, probably should not be deleting from it at the same time.  May also 
> want to wait until all the other tables in the schema are removed before 
> delete histogram tables (or delete the histogram tables first).
> Prototyped a change that:
> As part of cleanup schema, cleaned up all the non histogram tables first then 
> cleaned up the histogram tables.
> As part of dropping a histogram table, did not call dropSeabaseStats.
> This seemed to fix the problem.
> May want to handle failures from delete histogram rows better. Also, if 
> someone tries to cleanup one histogram table, perhaps all should be dropped.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (TRAFODION-1750) remove build dependency on qpid

2016-02-05 Thread liu ming (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

liu ming closed TRAFODION-1750.
---

> remove build dependency on qpid
> ---
>
> Key: TRAFODION-1750
> URL: https://issues.apache.org/jira/browse/TRAFODION-1750
> Project: Apache Trafodion
>  Issue Type: Improvement
>Reporter: liu ming
>Assignee: liu ming
>
> Trafodion build now has a dependency on qpid, but in fact, qpid is not used 
> inside Trafodion. It is just a legacy code dependency, some source code refer 
> to qpid but never used.
> So we can remove those unused functions/source-code to remove the dependency 
> for qpid, and simplify the preparation of a development environment. 
> Now one must install qpid-cpp-client-devel package in special way for CentOS 
> newer than 6.3, which is too old :
>  yum --enablerepo=C6.3-updates install qpid-cpp-client-devel
> This is one of the effort to make Trafodion development easier, we should 
> also try to clean up other legacy dependency as much as possible, this will 
> not only make build easier so as installation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (TRAFODION-1750) remove build dependency on qpid

2016-02-05 Thread liu ming (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

liu ming resolved TRAFODION-1750.
-
Resolution: Fixed

> remove build dependency on qpid
> ---
>
> Key: TRAFODION-1750
> URL: https://issues.apache.org/jira/browse/TRAFODION-1750
> Project: Apache Trafodion
>  Issue Type: Improvement
>Reporter: liu ming
>Assignee: liu ming
>
> Trafodion build now has a dependency on qpid, but in fact, qpid is not used 
> inside Trafodion. It is just a legacy code dependency, some source code refer 
> to qpid but never used.
> So we can remove those unused functions/source-code to remove the dependency 
> for qpid, and simplify the preparation of a development environment. 
> Now one must install qpid-cpp-client-devel package in special way for CentOS 
> newer than 6.3, which is too old :
>  yum --enablerepo=C6.3-updates install qpid-cpp-client-devel
> This is one of the effort to make Trafodion development easier, we should 
> also try to clean up other legacy dependency as much as possible, this will 
> not only make build easier so as installation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-1798) Support Transactions for DDL statements

2016-02-05 Thread Prashanth Vasudev (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Prashanth Vasudev updated TRAFODION-1798:
-
Description: 
This work to support transaction for DDL operations started before Trafodion 
became part of incubation as Apache Trafodion.  The initial link to the 
blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support

Some of the implementation to support this feature is already in code base, 
however there are some more additional changes needed to support completely.
Additional changes include:

0. Enable existing transactional DDL support in transaction manager. Also 
enable corresponding regression test.
1. SQL executor changes to leverage transactional DDL support by transaction 
manager.
2. Issue with simultaneous transactional update to the table followed by drop. 
This manifests as a hang when a drop schema is performed.
3. Recovery in case of HA failure scenario.

  was:
This work to support transaction for DDL operations started before Trafodion 
became part of incubation as Apache Trafodion.  The initial link to the 
blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support

Some of the implementation to support this feature is already in code base, 
however there are some more additional changes needed to support completely.
Additional changes include:

1. SQL executor changes to leverage transactional DDL support by transaction 
manager.
2. Issue with simultaneous transactional update to the table followed by drop. 
This manifests as a hang when a drop schema is performed.
3. Recovery in case of HA failure scenario.



> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134274#comment-15134274
 ] 

ASF GitHub Bot commented on TRAFODION-1798:
---

GitHub user prashanth-vasudev opened a pull request:

https://github.com/apache/incubator-trafodion/pull/309

TRAFODION-1798- Enable DDL transaction infrastructure by default.

This is Step 0 ( of 4 steps ) as outlined in the jira TRAFODION-1798

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/prashanth-vasudev/incubator-trafodion 
TRAFODION-1798

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-trafodion/pull/309.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 #309


commit 5ce375fbb1814c533f6b1331197e7959ff99
Author: Prashant Vasudev 
Date:   2016-02-05T14:35:55Z

TRAFODION-1798- Enable DDL transaction infrastructure by default.
This is Step 0 ( of 4 steps ) as outlined in the jira.




> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (TRAFODION-1814) REST Servers' pstack API does not return pstack information of process

2016-02-05 Thread Venkat Muthuswamy (JIRA)
Venkat Muthuswamy created TRAFODION-1814:


 Summary: REST Servers' pstack API does not return pstack 
information of process
 Key: TRAFODION-1814
 URL: https://issues.apache.org/jira/browse/TRAFODION-1814
 Project: Apache Trafodion
  Issue Type: Bug
Reporter: Venkat Muthuswamy






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (TRAFODION-1814) REST Servers' pstack API does not return pstack information of process

2016-02-05 Thread Venkat Muthuswamy (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Venkat Muthuswamy updated TRAFODION-1814:
-
Description: 
The REST servers pstack api does not work as expected. The REST API uses the 
sqpstack script under the covers. While the sqpstack works as expected, the 
REST APIs do not return the complete results.

The API to get pstack of all processes does not return information for all 
processes. For example if sqpstack returns pstack for 2 processes, only the 
first pstack information is returned.
 http://:4200/v1/servers/pstack

The API to get pstack for a user specified process returns an exception instead 
of the pstack info, even though the underlying sqpstack command works fine.
http://:4200/v1/servers/pstack/program/

The response is an exception string
{
  "RemoteException": {
"javaClassName": "org.trafodion.rest.NotFoundException",
"exception": "NotFoundException",
"message": "No pstack resources found"
  }
}

> REST Servers' pstack API does not return pstack information of process
> --
>
> Key: TRAFODION-1814
> URL: https://issues.apache.org/jira/browse/TRAFODION-1814
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Venkat Muthuswamy
>
> The REST servers pstack api does not work as expected. The REST API uses the 
> sqpstack script under the covers. While the sqpstack works as expected, the 
> REST APIs do not return the complete results.
> The API to get pstack of all processes does not return information for all 
> processes. For example if sqpstack returns pstack for 2 processes, only the 
> first pstack information is returned.
>  http://:4200/v1/servers/pstack
> The API to get pstack for a user specified process returns an exception 
> instead of the pstack info, even though the underlying sqpstack command works 
> fine.
> http://:4200/v1/servers/pstack/program/
> The response is an exception string
> {
>   "RemoteException": {
> "javaClassName": "org.trafodion.rest.NotFoundException",
> "exception": "NotFoundException",
> "message": "No pstack resources found"
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (TRAFODION-1798) Support Transactions for DDL statements

2016-02-05 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/TRAFODION-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135327#comment-15135327
 ] 

ASF GitHub Bot commented on TRAFODION-1798:
---

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-trafodion/pull/309


> Support Transactions for DDL statements
> ---
>
> Key: TRAFODION-1798
> URL: https://issues.apache.org/jira/browse/TRAFODION-1798
> Project: Apache Trafodion
>  Issue Type: New Feature
>Reporter: Prashanth Vasudev
>Assignee: Prashanth Vasudev
> Attachments: TransactionsDDL_Apache.pdf
>
>
> This work to support transaction for DDL operations started before Trafodion 
> became part of incubation as Apache Trafodion.  The initial link to the 
> blueprint is https://blueprints.launchpad.net/trafodion/+spec/dtm-ddl-support
> Some of the implementation to support this feature is already in code base, 
> however there are some more additional changes needed to support completely.
> Additional changes include:
> 0. Enable existing transactional DDL support in transaction manager. Also 
> enable corresponding regression test.
> 1. SQL executor changes to leverage transactional DDL support by transaction 
> manager.
> 2. Issue with simultaneous transactional update to the table followed by 
> drop. This manifests as a hang when a drop schema is performed.
> 3. Recovery in case of HA failure scenario.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Work started] (TRAFODION-1814) REST Servers' pstack API does not return pstack information of process

2016-02-05 Thread Venkat Muthuswamy (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRAFODION-1814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on TRAFODION-1814 started by Venkat Muthuswamy.

> REST Servers' pstack API does not return pstack information of process
> --
>
> Key: TRAFODION-1814
> URL: https://issues.apache.org/jira/browse/TRAFODION-1814
> Project: Apache Trafodion
>  Issue Type: Bug
>Reporter: Venkat Muthuswamy
>Assignee: Venkat Muthuswamy
>
> The REST servers pstack api does not work as expected. The REST API uses the 
> sqpstack script under the covers. While the sqpstack works as expected, the 
> REST APIs do not return the complete results.
> The API to get pstack of all processes does not return information for all 
> processes. For example if sqpstack returns pstack for 2 processes, only the 
> first pstack information is returned.
>  http://:4200/v1/servers/pstack
> The API to get pstack for a user specified process returns an exception 
> instead of the pstack info, even though the underlying sqpstack command works 
> fine.
> http://:4200/v1/servers/pstack/program/
> The response is an exception string
> {
>   "RemoteException": {
> "javaClassName": "org.trafodion.rest.NotFoundException",
> "exception": "NotFoundException",
> "message": "No pstack resources found"
>   }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)