[jira] [Commented] (TRAFODION-1959) multiple data file in HDFS will cause bulkloader fail
[ https://issues.apache.org/jira/browse/TRAFODION-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15270047#comment-15270047 ] liu ming commented on TRAFODION-1959: - core dump info: #0 0x003892432625 in raise () from /lib64/libc.so.6 #1 0x003892433e05 in abort () from /lib64/libc.so.6 #2 0x7f345f2b2785 in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91.x86_64/jre/lib/amd64/server/libjvm.so #3 0x7f345f42603f in ?? () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91.x86_64/jre/lib/amd64/server/libjvm.so #4 0x7f345f2b7322 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.91.x86_64/jre/lib/amd64/server/libjvm.so #5 #6 _M_data (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:278 #7 _M_rep (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:286 #8 size (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:629 #9 compare (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:2021 #10 operator< , std::allocator > (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/basic_string.h:2317 #11 operator() (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_function.h:230 #12 _M_lower_bound (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:986 #13 find (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_tree.h:1421 #14 find (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../include/c++/4.4.7/bits/stl_map.h:659 #15 ExLob::openDataCursor (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, waited=0, lobGlobals=0xc7c8c0) at ../exp/ExpLOBaccess.cpp:1074 #16 0x7f3460dd4783 in ExLobGlobals::processPreOpens (this=0xc7c8c0) at ../exp/ExpLOBaccess.cpp:3123 #17 0x7f3460dd4b09 in ExLobGlobals::performRequest (this=0xc7c8c0, request=) at ../exp/ExpLOBaccess.cpp:2651 #18 0x7f3460dd4cb9 in ExLobGlobals::doWorkInThread (this=0xc7c8c0) at ../exp/ExpLOBaccess.cpp:3087 ---Type to continue, or q to quit--- #19 0x7f3460dd4d09 in workerThreadMain (arg=) at ../exp/ExpLOBaccess.cpp:2867 #20 0x003892807a51 in start_thread () from /lib64/libpthread.so.0 #21 0x0038924e893d in clone () from /lib64/libc.so.6 (gdb) frame 15 #15 ExLob::openDataCursor (this=0x20b0b40, file=0x7f344bc149f8 "hdfs://esg06.esgyncn.local:8020/px/td/devices_94075.txt:7f34546e4d98:366", type=Lob_Cursor_Simple, range=939524096, bufMaxSize=67108864, maxBytes=56803570, wai
[jira] [Commented] (TRAFODION-532) LP Bug: 1355038 - SPJ w result set failed with ERROR[8841]
[
https://issues.apache.org/jira/browse/TRAFODION-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269944#comment-15269944
]
Kevin Xu commented on TRAFODION-532:
Selva, Sure, i'll take a look.
> LP Bug: 1355038 - SPJ w result set failed with ERROR[8841]
> --
>
> Key: TRAFODION-532
> URL: https://issues.apache.org/jira/browse/TRAFODION-532
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Chong Hsu
>Assignee: Kevin Xu
>Priority: Critical
> Fix For: 1.0 (pre-incubation)
>
>
> SPJ w result set failed with ERROR[8841]
> Tested with Trafodion build, 20140801-0830.
> Calling a SPJ with result set:
>public static void RS292(ResultSet[] paramArrayOfResultSet) throws
> Exception
>{
> String str = "jdbc:default:connection";
>
> Connection localConnection = DriverManager.getConnection(str);
> Statement localStatement = localConnection.createStatement();
> paramArrayOfResultSet[0] = localStatement.executeQuery("select *
> from(delete from testtab where e_code>2 return old.*) as t1");
>}
> it failed with ERROR[8841]:
> *** ERROR[8841] User application committed or aborted a transaction started
> by SQL. This transaction needs to be committed or aborted by calling SQL
> COMMIT or ROLLBACK WORK. [2014-08-11 04:30:14]
> The SPJ Jar file is attached. Here are the steps to produce the error:
>
> set schema testspj;
> create library spjrs file '//Testrs.jar';
> create procedure RS292()
> language java parameter style java
> library spjrs
> dynamic result sets 3
> external name 'Testrs.RS292';
> Call RS292();
> *** ERROR[8841] User application committed or aborted a transaction started
> by SQL. This transaction needs to be committed or aborted by calling SQL
> COMMIT or ROLLBACK WORK. [2014-08-11 04:30:14]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TRAFODION-532) LP Bug: 1355038 - SPJ w result set failed with ERROR[8841]
[
https://issues.apache.org/jira/browse/TRAFODION-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan reassigned TRAFODION-532:
---
Assignee: Kevin Xu (was: Selvaganesan Govindarajan)
Kevin,
This JIRA was assigned to me long ago. Will you be able to work on this?
> LP Bug: 1355038 - SPJ w result set failed with ERROR[8841]
> --
>
> Key: TRAFODION-532
> URL: https://issues.apache.org/jira/browse/TRAFODION-532
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Chong Hsu
>Assignee: Kevin Xu
>Priority: Critical
> Fix For: 1.0 (pre-incubation)
>
>
> SPJ w result set failed with ERROR[8841]
> Tested with Trafodion build, 20140801-0830.
> Calling a SPJ with result set:
>public static void RS292(ResultSet[] paramArrayOfResultSet) throws
> Exception
>{
> String str = "jdbc:default:connection";
>
> Connection localConnection = DriverManager.getConnection(str);
> Statement localStatement = localConnection.createStatement();
> paramArrayOfResultSet[0] = localStatement.executeQuery("select *
> from(delete from testtab where e_code>2 return old.*) as t1");
>}
> it failed with ERROR[8841]:
> *** ERROR[8841] User application committed or aborted a transaction started
> by SQL. This transaction needs to be committed or aborted by calling SQL
> COMMIT or ROLLBACK WORK. [2014-08-11 04:30:14]
> The SPJ Jar file is attached. Here are the steps to produce the error:
>
> set schema testspj;
> create library spjrs file '//Testrs.jar';
> create procedure RS292()
> language java parameter style java
> library spjrs
> dynamic result sets 3
> external name 'Testrs.RS292';
> Call RS292();
> *** ERROR[8841] User application committed or aborted a transaction started
> by SQL. This transaction needs to be committed or aborted by calling SQL
> COMMIT or ROLLBACK WORK. [2014-08-11 04:30:14]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TRAFODION-1923) executor/TEST106 hangs at drop table at times
[ https://issues.apache.org/jira/browse/TRAFODION-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269930#comment-15269930 ] ASF GitHub Bot commented on TRAFODION-1923: --- GitHub user prashanth-vasudev opened a pull request: https://github.com/apache/incubator-trafodion/pull/463 Fix for TRAFODION-1923 Basically, we now understand why SQL was not able to close the outstanding scanner , 1. because of cancel and the plan involved esps, it was the esps that get killed which did not have an option to close the scanner. 2. Because of this stale scanner is found in region when drop table is issued. 3. Chore thread in region is able to clean the stale scanner, however it may kick in at different times. 4. A drop table issued in the meantime appears as hung since region observer intercepts the region close ( due to drop table) and finds a stale scanner. 5. Fix is to detect this situation in regionobserver and validate if a transaction state object exists for this scanner. If it exists, then the intercept is valid, otherwise let the region close complete. I have pushed the code and did a PR request so you can review the changes. However, committers wait till all the regressions in my dev environment complete ( I will send out a message once its done). You can merge this pull request into a Git repository by running: $ git pull https://github.com/prashanth-vasudev/incubator-trafodion trafodion-1923 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/463.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 #463 > executor/TEST106 hangs at drop table at times > - > > Key: TRAFODION-1923 > URL: https://issues.apache.org/jira/browse/TRAFODION-1923 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Prashanth Vasudev >Priority: Critical > Fix For: 2.0-incubating > > > executor/TEST106 hangs at > drop table t106a > Currently executor/TEST106 test is not run as part of Daily regression build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TRAFODION-1928) Trafodion daily build regression in CDH distro fails in hive tests
[ https://issues.apache.org/jira/browse/TRAFODION-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-1928. -- Resolution: Fixed Fix Version/s: 2.0-incubating https://github.com/apache/incubator-trafodion/pull/413 > Trafodion daily build regression in CDH distro fails in hive tests > -- > > Key: TRAFODION-1928 > URL: https://issues.apache.org/jira/browse/TRAFODION-1928 > Project: Apache Trafodion > Issue Type: Bug > Components: installer >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Critical > Fix For: 2.0-incubating > > > All tests involving Hive fails in daily build regressions in CDH distro. The > class org/apache/hadoop/mapred/MRVersion is not found in the CLASSPATH in > ms.env. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TRAFODION-1923) executor/TEST106 hangs at drop table at times
[ https://issues.apache.org/jira/browse/TRAFODION-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-1923: Assignee: Prashanth Vasudev (was: Selvaganesan Govindarajan) Thanks Prashanth for working on this issue > executor/TEST106 hangs at drop table at times > - > > Key: TRAFODION-1923 > URL: https://issues.apache.org/jira/browse/TRAFODION-1923 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Prashanth Vasudev >Priority: Critical > Fix For: 2.0-incubating > > > executor/TEST106 hangs at > drop table t106a > Currently executor/TEST106 test is not run as part of Daily regression build. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1964) Cannot run SPJs after an trafodion upgrade
[ https://issues.apache.org/jira/browse/TRAFODION-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269881#comment-15269881 ] Hans Zeller commented on TRAFODION-1964: Note also, Venkat, that this means you will need to change your CREATE LIBRARY statement to use a relative name once this fix is in. > Cannot run SPJs after an trafodion upgrade > --- > > Key: TRAFODION-1964 > URL: https://issues.apache.org/jira/browse/TRAFODION-1964 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Venkat Muthuswamy >Assignee: Hans Zeller > > The system and user SPJ jar files are now stored under > $MY_SQROOT/udr/lib/. > The CREATE LIBRARY/ALTER LIBRARY commands use the fully qualified linux > directory paths (the environment variables are expanded). > For example, if current trafodion build is installed under > /home/trafodion/build1, the files are stored under > /home/trafodion/build1/udr/lib/user1 > When the user upgrades and installs a new build, let's say trafodion is > installed under /home/trafodion/build2. > If the user removes this old trafodion installation, the libraries and SPJs > defined using build1 no longer work, because the UDR tries to load the jar > file from /home/trafodion/build1/udr/lib/user1 folder because that's what is > stored in the metadata. > Even if the folder exists, any system created library would be pointing to an > older version of the jar file even though the new install might include fixes > to the system library jar. > 1. Can the CREATE and ALTER LIBRARY commands use relative paths to something > like $MY_UDR_ROOT and not required the fully qualified paths? > 2. Can the UDR runtime be modified to look at the relative paths $MY_UDR_ROOT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1964) Cannot run SPJs after an trafodion upgrade
[ https://issues.apache.org/jira/browse/TRAFODION-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269877#comment-15269877 ] Hans Zeller commented on TRAFODION-1964: What I can do is replace the "." (or empty string) in the external library path with $MY_SQROOT/udr/lib/DB__ROOT and load any libraries with relative names from there. All the remaining code, DDL and DML accepts relative names. Note that this introduces an incompatibility for use cases with relative names, but with the current code, relative names would not work well, since the current work directory of the UDR server is not clearly specified. For TMUDFs it's nearly impossible, since two different work directories could be involved. If you run into this incompatibility, relocate your library files from where they are right now (likely in $MY_SQROOT/sql/scripts??) to $MY_SQROOT/udr/lib/DB__ROOT. > Cannot run SPJs after an trafodion upgrade > --- > > Key: TRAFODION-1964 > URL: https://issues.apache.org/jira/browse/TRAFODION-1964 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Venkat Muthuswamy >Assignee: Hans Zeller > > The system and user SPJ jar files are now stored under > $MY_SQROOT/udr/lib/. > The CREATE LIBRARY/ALTER LIBRARY commands use the fully qualified linux > directory paths (the environment variables are expanded). > For example, if current trafodion build is installed under > /home/trafodion/build1, the files are stored under > /home/trafodion/build1/udr/lib/user1 > When the user upgrades and installs a new build, let's say trafodion is > installed under /home/trafodion/build2. > If the user removes this old trafodion installation, the libraries and SPJs > defined using build1 no longer work, because the UDR tries to load the jar > file from /home/trafodion/build1/udr/lib/user1 folder because that's what is > stored in the metadata. > Even if the folder exists, any system created library would be pointing to an > older version of the jar file even though the new install might include fixes > to the system library jar. > 1. Can the CREATE and ALTER LIBRARY commands use relative paths to something > like $MY_UDR_ROOT and not required the fully qualified paths? > 2. Can the UDR runtime be modified to look at the relative paths $MY_UDR_ROOT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (TRAFODION-1964) Cannot run SPJs after an trafodion upgrade
[ https://issues.apache.org/jira/browse/TRAFODION-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-1964 started by Hans Zeller. -- > Cannot run SPJs after an trafodion upgrade > --- > > Key: TRAFODION-1964 > URL: https://issues.apache.org/jira/browse/TRAFODION-1964 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Venkat Muthuswamy >Assignee: Hans Zeller > > The system and user SPJ jar files are now stored under > $MY_SQROOT/udr/lib/. > The CREATE LIBRARY/ALTER LIBRARY commands use the fully qualified linux > directory paths (the environment variables are expanded). > For example, if current trafodion build is installed under > /home/trafodion/build1, the files are stored under > /home/trafodion/build1/udr/lib/user1 > When the user upgrades and installs a new build, let's say trafodion is > installed under /home/trafodion/build2. > If the user removes this old trafodion installation, the libraries and SPJs > defined using build1 no longer work, because the UDR tries to load the jar > file from /home/trafodion/build1/udr/lib/user1 folder because that's what is > stored in the metadata. > Even if the folder exists, any system created library would be pointing to an > older version of the jar file even though the new install might include fixes > to the system library jar. > 1. Can the CREATE and ALTER LIBRARY commands use relative paths to something > like $MY_UDR_ROOT and not required the fully qualified paths? > 2. Can the UDR runtime be modified to look at the relative paths $MY_UDR_ROOT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-1968) Remove Hadoop settings set during install that are no longer needed
Amanda Moran created TRAFODION-1968: --- Summary: Remove Hadoop settings set during install that are no longer needed Key: TRAFODION-1968 URL: https://issues.apache.org/jira/browse/TRAFODION-1968 Project: Apache Trafodion Issue Type: Bug Components: installer Reporter: Amanda Moran Assignee: Amanda Moran Remove old settings that are being set for Hadoop in traf_*_mods https://docs.google.com/a/esgyn.com/spreadsheets/d/1jVta-F6Q0T_zHv_k1JJorrt_EjhG12EaSacrFO0y664/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1920) suppress SQL error during HIVE_SCAN when encounter invalid value, assign null to the invalid value
[ https://issues.apache.org/jira/browse/TRAFODION-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268929#comment-15268929 ] ASF GitHub Bot commented on TRAFODION-1920: --- Github user traflm closed the pull request at: https://github.com/apache/incubator-trafodion/pull/441 > suppress SQL error during HIVE_SCAN when encounter invalid value, assign null > to the invalid value > -- > > Key: TRAFODION-1920 > URL: https://issues.apache.org/jira/browse/TRAFODION-1920 > Project: Apache Trafodion > Issue Type: Sub-task >Reporter: liu ming >Assignee: liu ming > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TRAFODION-1920) suppress SQL error during HIVE_SCAN when encounter invalid value, assign null to the invalid value
[ https://issues.apache.org/jira/browse/TRAFODION-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15268927#comment-15268927 ] ASF GitHub Bot commented on TRAFODION-1920: --- GitHub user traflm opened a pull request: https://github.com/apache/incubator-trafodion/pull/461 [TRAFODION-1920] suppress SQL error during HIVE_SCAN when conv error A new PR for JIRA 1920. When read from HDFS in HIVE_SCAN and encounter invalid data, continue and set the offending data to null. Latest implementation details: In code gen of HIVE_SCAN, if the CQD HIVE_SCAN_SPECIAL_MODE is set to '2'. Generate a CAST function setting a special flag. In that CAST codegen, it will set runtime flag based on the special flag. This will create a special ex_conv_clause. Codegen also disable pCode in this mode. At runtime, ex_conv_caluse::eval() will move null into target if convDoIt() failed. And continue. You can merge this pull request into a Git repository by running: $ git pull https://github.com/traflm/incubator-trafodion TRAFODION-1920 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-trafodion/pull/461.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 #461 commit 67b89f8ad6c1dc0b30607d98d6e5a141a79ae3e2 Author: Liu Ming Date: 2016-05-03T15:48:03Z [TRAFODION-1920] suppress SQL error during HIVE_SCAN when conv error > suppress SQL error during HIVE_SCAN when encounter invalid value, assign null > to the invalid value > -- > > Key: TRAFODION-1920 > URL: https://issues.apache.org/jira/browse/TRAFODION-1920 > Project: Apache Trafodion > Issue Type: Sub-task >Reporter: liu ming >Assignee: liu ming > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-1967) [offline backup&restore] trafodion is not started automatically without -o option
Gao, Rui-Xian created TRAFODION-1967:
Summary: [offline backup&restore] trafodion is not started
automatically without -o option
Key: TRAFODION-1967
URL: https://issues.apache.org/jira/browse/TRAFODION-1967
Project: Apache Trafodion
Issue Type: Bug
Components: db-utility-backup-restore
Environment: Centos6.7 hbase1.0 CDH5.4.4
esgynDBadv-0430 build
Reporter: Gao, Rui-Xian
Priority: Minor
During backup, the output is like this --
Starting Trafodion...
sudo: unknown user: Trafodion
sudo: unable to initialize policy plugin
Trafodion not started. Please start Trafodion at your convinience.
trafodion user is hardcoded to 'Trafodion' in backup_restore_functions.sh, we
should use either 'trafodion' or a variable instead.
trafodion_user="Trafodion"
echo "Trafodion user name: $trafodion_user" | tee -a ${log_file}
else
echo "***[ERROR]: Did not find supported Hadoop distribution or $MY_SQROOT
is not set."
return 1
fi
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TRAFODION-1966) [offline backup&restore] TrafexportSnapshot ran into NoClassDefFoundError on HDP2.4
Gao, Rui-Xian created TRAFODION-1966: Summary: [offline backup&restore] TrafexportSnapshot ran into NoClassDefFoundError on HDP2.4 Key: TRAFODION-1966 URL: https://issues.apache.org/jira/browse/TRAFODION-1966 Project: Apache Trafodion Issue Type: Bug Components: db-utility-backup-restore Environment: centos6.7, hbase1.1 HDP2.4.0 Reporter: Gao, Rui-Xian offline backup on HDP2.4.0 will run into error -- ./run_full_trafodion_backup.sh Exporting TRAFODION.RACHEL_QA.IDX1_SNAP_20160503-2207 ... hbase org.trafodion.utility.backuprestore.TrafExportSnapshot -snapshot TRAFODION.RACHEL_QA.IDX1_SNAP_20160503-2207 -copy-to hdfs://suse-0.novalocal:8020/trafodion_backups/backup_20160503-2207/TRAFODION.RACHEL_QA.IDX1_SNAP_20160503-2207 -mappers 0 -mr-lowlimit-mb 100 2016-05-03 22:09:49,141 INFO [main] backuprestore.TrafExportSnapshot: Trafodion Export Snapshot Utility SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/usr/hdp/2.3.4.7-4/hadoop/lib/slf4j-log4j12-1.7.10.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/usr/hdp/2.3.4.7-4/zookeeper/lib/slf4j-log4j12-1.6.1.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] 2016-05-03 22:09:50,797 INFO [main] backuprestore.TrafExportSnapshot: Copy Snapshot Manifest 2016-05-03 22:09:51,246 INFO [main] backuprestore.TrafExportSnapshot: Loading Snapshot 'TRAFODION.RACHEL_QA.IDX1_SNAP_20160503-2207' hfile list 2016-05-03 22:09:51,487 INFO [main] backuprestore.TrafExportSnapshot: Copy Snapshot Data Files Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/hadoop/hbase/mob/MobUtils at org.trafodion.utility.backuprestore.TrafExportSnapshot.getCopyInputPath(TrafExportSnapshot.java:1052) at org.trafodion.utility.backuprestore.TrafExportSnapshot.run(TrafExportSnapshot.java:983) at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) at org.trafodion.utility.backuprestore.TrafExportSnapshot.innerMain(TrafExportSnapshot.java:1109) at org.trafodion.utility.backuprestore.TrafExportSnapshot.main(TrafExportSnapshot.java:1114) Caused by: java.lang.ClassNotFoundException: org.apache.hadoop.hbase.mob.MobUtils at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 5 more ***[ERROR]: Error while exporting snapshot: TRAFODION.RACHEL_QA.IDX1_SNAP_20160503-2207. For more information please check the logs at /home/trafodion/esgynDBadv-20160501_0830-bin/hbase_utilities/backup_and_restore/logs/run_traf_backup_20160503-2207.log. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
