[jira] [Updated] (TRAFODION-2664) Instance will be down when the zookeeper on name node has been down
[ https://issues.apache.org/jira/browse/TRAFODION-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek updated TRAFODION-2664: - Description: Description: Instance will be down when the zookeeper on name node has been down Test Steps: Step 1. Start OE and 4 long queries with trafci on the first node esggy-clu-n010 Step 2. Wait several minutes and stop zookeeper on name node of node esggy-clu-n010 in Cloudera Manager page. Step 3. With trafci, run a basic query and 4 long queries again. In the above Step 3, we will see the whole instance as down after a while. For this test scenario, I tried it several times, always found instance as down. Timestamp: Test Start Time: 20170616132939 Test End Time: 20170616134350 Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 Check logs: 1) Each node displays the following error: 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process Name: $MONITOR,,, TID: 5429, Message ID: 101371801, [CZClient::IsZNodeExpired], zoo_exists() for /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error ZCONNECTIONLOSS 2) Zookeeper displays: ls /trafodion/instance/cluster [] So, It seems zclient has been lost on each node. Location of logs: esggy-clu-n010: /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz and trafodion_logs.20170616134816.tar.gz By the way, because the size of the logs is out of the limited value, so i cannot upload it as the attachment in this JIRA ID. How many zookeeper quorum servers in the cluster? total 3. dcs.zookeeper.quorum esggy-clu-n010.esgyn.cn,esggy-clu-n011.esgyn.cn,esggy-clu-n012.esgyn.cn How to access the cluster? 1. Login 10.10.10.8 from US machine: trafodion/traf123 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 was: Description: Instance will be down when the zookeeper on name node has been down Test Steps: Step 1. Start OE and 4 long queries with trafci on the first node esggy-clu-n010 Step 2. Wait several minutes and stop zookeeper on name node of node esggy-clu-n010 in Cloudera Manager page. Step 3. With trafci, run a basic query and 4 long queries again. In the above Step 3, we will see the whole instance as down after a while. For this test scenario, I tried it several times, always found instance as down. Timestamp: Test Start Time: 20170616132939 Test End Time: 20170616134350 Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 Check logs: 1) Each node displays the following error: 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process Name: $MONITOR,,, TID: 5429, Message ID: 101371801, [CZClient::IsZNodeExpired], zoo_exists() for /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error ZCONNECTIONLOSS 2) Zookeeper displays: ls /trafodion/instance/cluster [] So, It seems zclient has been lost on each node. Location of logs: esggy-clu-n010: /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz and trafodion_logs.20170616134816.tar.gz By the way, because the size of the logs is out of the limited size, so i cannot upload it as the attachment in this JIRA ID. How many zookeeper quorum servers in the cluster? total 3. dcs.zookeeper.quorum esggy-clu-n010.esgyn.cn,esggy-clu-n011.esgyn.cn,esggy-clu-n012.esgyn.cn How to access the cluster? 1. Login 10.10.10.8 from US machine: trafodion/traf123 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 > Instance will be down when the zookeeper on name node has been down > --- > > Key: TRAFODION-2664 > URL: https://issues.apache.org/jira/browse/TRAFODION-2664 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Affects Versions: 2.2-incubating > Environment: Test Environment: > CDH5.4.8: 10.10.23.19:7180, total 6 nodes. > HDFS-HA and DCS-HA: enabled > OS: Centos6.8, physic machine. > SW Build: R2.2.3 (EsgynDB_Enterprise Release 2.2.3 (Build release [sbroeder], > branch 1ce8d39-xdc_nari, date 11Jun17) >Reporter: Jarek >Priority: Critical > Labels: build > Fix For: 2.2-incubating > > > Description: Instance will be down when the zookeeper on name node has been > down > Test Steps: > Step 1. Start OE and 4 long queries with trafci on the first node > esggy-clu-n010 > Step 2. Wait several minutes and stop zookeeper on name node of node > esggy-clu-n010 in Cloudera Manager page. > Step 3. With trafci, run a basic query and 4 long queries again. > In the above Step 3, we will see the whole instance as down after a while. > For this test scenario, I tried it several times, always found instance as > down. > Timestamp: > Test Start Time: 20170616132939 > Test End Time:
[jira] [Updated] (TRAFODION-2664) Instance will be down when the zookeeper on name node has been down
[ https://issues.apache.org/jira/browse/TRAFODION-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek updated TRAFODION-2664: - Description: Description: Instance will be down when the zookeeper on name node has been down Test Steps: Step 1. Start OE and 4 long queries with trafci on the first node esggy-clu-n010 Step 2. Wait several minutes and stop zookeeper on name node of node esggy-clu-n010 in Cloudera Manager page. Step 3. With trafci, run a basic query and 4 long queries again. In the above Step 3, we will see the whole instance as down after a while. For this test scenario, I tried it several times, always found instance as down. Timestamp: Test Start Time: 20170616132939 Test End Time: 20170616134350 Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 Check logs: 1) Each node displays the following error: 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process Name: $MONITOR,,, TID: 5429, Message ID: 101371801, [CZClient::IsZNodeExpired], zoo_exists() for /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error ZCONNECTIONLOSS 2) Zookeeper displays: ls /trafodion/instance/cluster [] So, It seems zclient has been lost on each node. Location of logs: esggy-clu-n010: /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz and trafodion_logs.20170616134816.tar.gz By the way, because the size of the logs is out of the limited size, so i cannot upload it as the attachment in this JIRA ID. How many zookeeper quorum servers in the cluster? total 3. dcs.zookeeper.quorum esggy-clu-n010.esgyn.cn,esggy-clu-n011.esgyn.cn,esggy-clu-n012.esgyn.cn How to access the cluster? 1. Login 10.10.10.8 from US machine: trafodion/traf123 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 was: Description: Instance will be down when the zookeeper on name node has been down Test Steps: Step 1. Start OE and 4 long queries with trafci on the first node esggy-clu-n010 Step 2. Wait several minutes and stop zookeeper on name node of node esggy-clu-n010 in Cloudera Manager page. Step 3. With trafci, run a basic query and 4 long queries again. In the above Step 3, we will see the whole instance as down after a while. For this test scenario, I tried it several times, always found instance as down. Timestamp: Test Start Time: 20170616132939 Test End Time: 20170616134350 Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 Check logs: 1) Each node displays the following error: 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process Name: $MONITOR,,, TID: 5429, Message ID: 101371801, [CZClient::IsZNodeExpired], zoo_exists() for /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error ZCONNECTIONLOSS 2) Zookeeper displays: ls /trafodion/instance/cluster [] So, It seems zclient has been lost on each node. Location of logs: esggy-clu-n010: /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz and trafodion_logs.20170616134816.tar.gz By the way, because the size of the logs is out of the limited size, so i cannot upload it as the attachment in this JIRA ID. How to access the cluster? 1. Login 10.10.10.8 from US machine: trafodion/traf123 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 > Instance will be down when the zookeeper on name node has been down > --- > > Key: TRAFODION-2664 > URL: https://issues.apache.org/jira/browse/TRAFODION-2664 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Affects Versions: 2.2-incubating > Environment: Test Environment: > CDH5.4.8: 10.10.23.19:7180, total 6 nodes. > HDFS-HA and DCS-HA: enabled > OS: Centos6.8, physic machine. > SW Build: R2.2.3 (EsgynDB_Enterprise Release 2.2.3 (Build release [sbroeder], > branch 1ce8d39-xdc_nari, date 11Jun17) >Reporter: Jarek >Priority: Critical > Labels: build > Fix For: 2.2-incubating > > > Description: Instance will be down when the zookeeper on name node has been > down > Test Steps: > Step 1. Start OE and 4 long queries with trafci on the first node > esggy-clu-n010 > Step 2. Wait several minutes and stop zookeeper on name node of node > esggy-clu-n010 in Cloudera Manager page. > Step 3. With trafci, run a basic query and 4 long queries again. > In the above Step 3, we will see the whole instance as down after a while. > For this test scenario, I tried it several times, always found instance as > down. > Timestamp: > Test Start Time: 20170616132939 > Test End Time: 20170616134350 > Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 > Check logs: > 1) Each node displays the following error: > 2017-06-16 13:33:46,276, ERROR,
[jira] [Created] (TRAFODION-2664) Instance will be down when the zookeeper on name node has been down
Jarek created TRAFODION-2664: Summary: Instance will be down when the zookeeper on name node has been down Key: TRAFODION-2664 URL: https://issues.apache.org/jira/browse/TRAFODION-2664 Project: Apache Trafodion Issue Type: Bug Components: foundation Affects Versions: 2.2-incubating Environment: Test Environment: CDH5.4.8: 10.10.23.19:7180, total 6 nodes. HDFS-HA and DCS-HA: enabled OS: Centos6.8, physic machine. SW Build: R2.2.3 (EsgynDB_Enterprise Release 2.2.3 (Build release [sbroeder], branch 1ce8d39-xdc_nari, date 11Jun17) Reporter: Jarek Priority: Critical Fix For: 2.2-incubating Description: Instance will be down when the zookeeper on name node has been down Test Steps: Step 1. Start OE and 4 long queries with trafci on the first node esggy-clu-n010 Step 2. Wait several minutes and stop zookeeper on name node of node esggy-clu-n010 in Cloudera Manager page. Step 3. With trafci, run a basic query and 4 long queries again. In the above Step 3, we will see the whole instance as down after a while. For this test scenario, I tried it several times, always found instance as down. Timestamp: Test Start Time: 20170616132939 Test End Time: 20170616134350 Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 Check logs: 1) Each node displays the following error: 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process Name: $MONITOR,,, TID: 5429, Message ID: 101371801, [CZClient::IsZNodeExpired], zoo_exists() for /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error ZCONNECTIONLOSS 2) Zookeeper displays: ls /trafodion/instance/cluster [] So, It seems zclient has been lost on each node. Location of logs: esggy-clu-n010: /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz and trafodion_logs.20170616134816.tar.gz By the way, because the size of the logs is out of the limited size, so i cannot upload it as the attachment in this JIRA ID. How to access the cluster? 1. Login 10.10.10.8 from US machine: trafodion/traf123 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2070) Trafodion cannot adjust your working status in time when network broken.
Jarek created TRAFODION-2070: Summary: Trafodion cannot adjust your working status in time when network broken. Key: TRAFODION-2070 URL: https://issues.apache.org/jira/browse/TRAFODION-2070 Project: Apache Trafodion Issue Type: Bug Components: dtm Affects Versions: 2.0-incubating, 2.1-incubating Reporter: Jarek Issue Title: Trafodion cannot adjust your working status in time when network broken. Test Steps (including part 1 and part 2): Preconditoin: the testing environment is good, including HDFS, HBase and EsgnDB. Part 1: Network broken occurred for a long time, here limit it as 15 minutes. Step 0. We login a traci interface to run a SQL statement ‘STMT_A’, like insert/delete/update/select, at the same time, the sql statement has running for several minutes. Step 1. Use command ‘iptables -I INPUT -s $NODE_HOST -j DROP’ to make nap104 node’s network unreachable for 15 minutes. Step 2. Start to do check Step 0, major SQL command and HDFS/HBase running status. Here, check Step 0 and major SQL command should be on nap101, nap102 and nap103 nodes. T-1 : Step 0 Comments Expect 1. When TRAFCI is connected to nap104 node, the SQL statement ‘STMT_A’ run failed and exit TRAFCI normally. 2. When TRAFCI is connected to nap101/nap102/nap103 node, the SQL statement ‘STMT_A’ run success and exit TRAFCI normally. Actual For expect 1: ISSUE 1: By checking the QID status of the SQL statement ‘STMT_A’, it normally displays “SQL>get statistics for qid MXID110030258942123314457118951450206U300_339_SQL_CUR_7; *** ERROR[2024] Server Process $ZSM003 is not running or could not be created. Operating System Error 14 was returned. [2016-05-31 09:22:48]”, back to TRAFCI interface, the SQL statement ‘STMT_A’ cannot be return in time but hang for a long time. ISSUE 2: At the same time, open a new TRAFCI that is connected to other node for example nap102, do SQL query statement ‘STMT_B’, using command ‘./offender -s active’ to check the QID status of the SQL statement ‘STMT_B’, but print the following error and say 0 row(s) selected “*** ERROR[8921] The request to obtain runtime statistics for ACTIVE_QUERIES=30 timed out. Timeout period specified is 4 seconds. --- 0 row(s) selected.” ISSUE 3: back to the TRAFCI session of ‘STMT_A’ and ‘STMT_B’, we can see these TRAFCI sessions are interrupted because of the below error. “SQL>select [last 1] * from TRAFODION.JAVABENCH.YCSB_TABLE_20; *** ERROR[29157] There was a problem reading from the server *** ERROR[29160] The message header was not long enough SQL>insert into josh_test_after values (1); *** ERROR[29443] Database connection does not exist. Please connect to the database by using the connect or the reconnect command.”. For expect 2: ISSUE 1: By checking the QID status of the SQL statement ‘STMT_A’, it normally displays “SQL>get statistics for qid MXID110020366282123314488178785910206U300_325_SQL_CUR_5;+> Qid MXID110020366282123314488178785910206U300_325_SQL_CUR_5 Compile Start Time 2016/05/31 10:02:56.968052 Compile End Time 2016/05/31 10:02:59.207231 Compile Elapsed Time 0:00:02.239179 Execute Start Time 2016/05/31 10:02:59.207468 Execute End Time -1 Execute Elapsed Time 0:05:46.731948 StateCLOSE”, back to TRAFCI interface, the SQL statement ‘STMT_A’ cannot be return in time but hang for a long time. ISSUE 2: at the same time, open a new TRAFCI that is connected to other node for example nap102, do SQL query statement ‘STMT_B’, using command ‘./offender -s active’ to check the QID status of the SQL statement ‘STMT_B’, but print the following error and say 0 row(s) selected “*** ERROR[8921] The request to obtain runtime statistics for ACTIVE_QUERIES=30 timed out. Timeout period specified is 4 seconds. --- 0 row(s) selected. >>” BTW, All TRAFCI session of ‘STMT_A’ and ‘STMT_B’ are closed normally. T-2 Command: sqcheckDTM DownRMS DownDCS Master Down DCS Server Down MxoSrvr DownComments Expect 1 2 0 1 4 Return in 1 minute Actual 1 2 0 1 4 Return in 1 minute T-3 Command: dcscheck DCS Master Down DCS Server Down MxoSrvr DownComments Expect 0 1 4 Return in 1 minute Actual 0 1 4 Return about 5 minutes T-4 Command: shell -c node info Comments Expect Only nap104 node down, return in 30 seconds Actual Only nap104 node down, return in 10 seconds T-5 Command: cstat Comments Expect Return in 30 seconds. Actual Return about 3 minutes. T-6 Commands: trafciComments Expect 1. Login success, Return in 1 minute whatever login success or failed. 2. Run new
[jira] [Updated] (TRAFODION-2063) SQL Errror 8102 occurred when down the region server
[ https://issues.apache.org/jira/browse/TRAFODION-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek updated TRAFODION-2063: - Affects Version/s: 2.0-incubating > SQL Errror 8102 occurred when down the region server > > > Key: TRAFODION-2063 > URL: https://issues.apache.org/jira/browse/TRAFODION-2063 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: 2.0-incubating, 2.1-incubating > Environment: OS Type and Version: Centos release 6.7 > Trafodion SW Version: 2.1 > CDH Version: 5.5.4 > JDK Version: 1.7.0_67 >Reporter: Jarek > Attachments: > coast_2016-06-08_16.05.46.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > > > Issue Description: > The following SQL Error 8102 occurred when down an region server. > "16:09:28 ***ERROR: SQLExecDirect: Expected: SQL_SUCCESS Actual: SQL_ERROR >File: ../../../../src/coast/coast_unified/src/jmtload.c Line: 187 >State: 23000 >Native Error: 4294959194 >Error: [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** > ERROR[8102] The operation is prevented by a unique constraint. [2016-06-08 > 16:09:28]" > > Steps: > Steps (cluster administrator page http://10.10.10.161:7180, username: admin, > password: admin) > Step 1. Enable High Availability in cluster testing environment. > Step 2. Run multi threads program that have connected to 32 mxosrsvr(s). > Step 3. Stop region server on centosha-5.novalocal node > Step 4. Check output of the multi threads program. > 1) output as below, > DEBUG: plan to delete total rows is 180385 > DEBUG: remaining rows to delete is 180296 > DEBUG: Remaining rows 310886 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 89 > DEBUG: Missing insertion rows 25 # please note > the missing insertion rows because of the above error 8102. > Total Tests=1 Failed=1 > 2) log file attached, > “/opt/share/jarek/testing/odbc/builds_unix/coast/unified/linux64/coast_2016-06-08_16.05.46.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log”. > BTW, our table structure is below, and we can see the cache size is 25 that > is used to avoid concurrency conflict when insert data by multi threads > program, but it still occurred. > > SQL>showddl trafodion.j_schema_2.j_table_1; > > > CREATE TABLE TRAFODION.J_SCHEMA_2.J_TABLE_1 > ( > C0 LARGEINT GENERATED BY DEFAULT AS IDENTITY > ( START WITH 1 INCREMENT BY 1 MAXVALUE 9223372036854775806 MINVALUE > 1 >CACHE 25 NO CYCLE LARGEINT ) NOT NULL NOT DROPPABLE SERIALIZED > , C1 CHAR(20) CHARACTER SET ISO88591 COLLATE > DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED > , C2 INT NO DEFAULT SERIALIZED > , C3 SMALLINT NO DEFAULT NOT NULL NOT > DROPPABLE > SERIALIZED > , C4 DOUBLE PRECISION DEFAULT > -1.727233711019E-76 NOT SERIALIZED > , C5 DOUBLE PRECISION DEFAULT > -2.2250738585072014E-308 NOT NULL NOT DROPPABLE NOT SERIALIZED > , C6 DATE DEFAULT CURRENT NOT SERIALIZED > , C7 TIME(0) DEFAULT CURRENT NOT SERIALIZED > , C8 DECIMAL(18, 10) DEFAULT > 12345678.1234567890 NOT NULL NOT DROPPABLE NOT SERIALIZED > , C9 LARGEINT DEFAULT 9.223E18 SERIALIZED > , C10 NUMERIC(128, 0) DEFAULT > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678 > NOT NULL NOT DROPPABLE NOT SERIALIZED > , C11 REAL DEFAULT -1.1579208E38 NOT SERIALIZED > , C12 INTERVAL YEAR(5) TO MONTH DEFAULT NULL > NOT > SERIALIZED > , C13 CHAR(12) CHARACTER SET ISO88591 COLLATE > DEFAULT UPSHIFT DEFAULT _ISO88591'defaULT' SERIALIZED > , C14 CHAR(8) CHARACTER SET ISO88591 COLLATE > DEFAULT DEFAULT _ISO88591'summer' SERIALIZED > , C15 VARCHAR(10) CHARACTER SET ISO88591 > COLLATE > DEFAULT DEFAULT _ISO88591'china' SERIALIZED > , CTIMESTAMP(6) DEFAULT CURRENT NOT > SERIALIZED > , PRIMARY KEY (C0 ASC) > ) > ; > > -- The following sequence is a system created sequence -- > > CREATE SEQUENCE TRAFODION.J_SCHEMA_2."_TRAFODION_J_SCHEMA_2_J_TABLE_1_C0_" /* > INTERNAL */ > START WITH 1 /* NEXT AVAILABLE VALUE 311001 */ > INCREMENT BY 1 > MAXVALUE 9223372036854775806 > MINVALUE 1 > CACHE 25 > NO CYCLE > LARGEINT > ; > > --- SQL operation
[jira] [Updated] (TRAFODION-2063) SQL Errror 8102 occurred when down the region server
[ https://issues.apache.org/jira/browse/TRAFODION-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek updated TRAFODION-2063: - Attachment: coast_2016-06-08_16.05.46.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > SQL Errror 8102 occurred when down the region server > > > Key: TRAFODION-2063 > URL: https://issues.apache.org/jira/browse/TRAFODION-2063 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: 2.1-incubating > Environment: OS Type and Version: Centos release 6.7 > Trafodion SW Version: 2.1 > CDH Version: 5.5.4 > JDK Version: 1.7.0_67 >Reporter: Jarek > Attachments: > coast_2016-06-08_16.05.46.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > > > Issue Description: > The following SQL Error 8102 occurred when down an region server. > "16:09:28 ***ERROR: SQLExecDirect: Expected: SQL_SUCCESS Actual: SQL_ERROR >File: ../../../../src/coast/coast_unified/src/jmtload.c Line: 187 >State: 23000 >Native Error: 4294959194 >Error: [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** > ERROR[8102] The operation is prevented by a unique constraint. [2016-06-08 > 16:09:28]" > > Steps: > Steps (cluster administrator page http://10.10.10.161:7180, username: admin, > password: admin) > Step 1. Enable High Availability in cluster testing environment. > Step 2. Run multi threads program that have connected to 32 mxosrsvr(s). > Step 3. Stop region server on centosha-5.novalocal node > Step 4. Check output of the multi threads program. > 1) output as below, > DEBUG: plan to delete total rows is 180385 > DEBUG: remaining rows to delete is 180296 > DEBUG: Remaining rows 310886 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 89 > DEBUG: Missing insertion rows 25 # please note > the missing insertion rows because of the above error 8102. > Total Tests=1 Failed=1 > 2) log file attached, > “/opt/share/jarek/testing/odbc/builds_unix/coast/unified/linux64/coast_2016-06-08_16.05.46.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log”. > BTW, our table structure is below, and we can see the cache size is 25 that > is used to avoid concurrency conflict when insert data by multi threads > program, but it still occurred. > > SQL>showddl trafodion.j_schema_2.j_table_1; > > > CREATE TABLE TRAFODION.J_SCHEMA_2.J_TABLE_1 > ( > C0 LARGEINT GENERATED BY DEFAULT AS IDENTITY > ( START WITH 1 INCREMENT BY 1 MAXVALUE 9223372036854775806 MINVALUE > 1 >CACHE 25 NO CYCLE LARGEINT ) NOT NULL NOT DROPPABLE SERIALIZED > , C1 CHAR(20) CHARACTER SET ISO88591 COLLATE > DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE SERIALIZED > , C2 INT NO DEFAULT SERIALIZED > , C3 SMALLINT NO DEFAULT NOT NULL NOT > DROPPABLE > SERIALIZED > , C4 DOUBLE PRECISION DEFAULT > -1.727233711019E-76 NOT SERIALIZED > , C5 DOUBLE PRECISION DEFAULT > -2.2250738585072014E-308 NOT NULL NOT DROPPABLE NOT SERIALIZED > , C6 DATE DEFAULT CURRENT NOT SERIALIZED > , C7 TIME(0) DEFAULT CURRENT NOT SERIALIZED > , C8 DECIMAL(18, 10) DEFAULT > 12345678.1234567890 NOT NULL NOT DROPPABLE NOT SERIALIZED > , C9 LARGEINT DEFAULT 9.223E18 SERIALIZED > , C10 NUMERIC(128, 0) DEFAULT > > 12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678 > NOT NULL NOT DROPPABLE NOT SERIALIZED > , C11 REAL DEFAULT -1.1579208E38 NOT SERIALIZED > , C12 INTERVAL YEAR(5) TO MONTH DEFAULT NULL > NOT > SERIALIZED > , C13 CHAR(12) CHARACTER SET ISO88591 COLLATE > DEFAULT UPSHIFT DEFAULT _ISO88591'defaULT' SERIALIZED > , C14 CHAR(8) CHARACTER SET ISO88591 COLLATE > DEFAULT DEFAULT _ISO88591'summer' SERIALIZED > , C15 VARCHAR(10) CHARACTER SET ISO88591 > COLLATE > DEFAULT DEFAULT _ISO88591'china' SERIALIZED > , CTIMESTAMP(6) DEFAULT CURRENT NOT > SERIALIZED > , PRIMARY KEY (C0 ASC) > ) > ; > > -- The following sequence is a system created sequence -- > > CREATE SEQUENCE TRAFODION.J_SCHEMA_2."_TRAFODION_J_SCHEMA_2_J_TABLE_1_C0_" /* > INTERNAL */ > START WITH 1 /* NEXT AVAILABLE VALUE 311001 */ > INCREMENT BY 1 > MAXVALUE 9223372036854775806 > MINVALUE 1 > CACHE 25 > NO CYCLE > LARGEINT > ;
[jira] [Closed] (TRAFODION-2061) SQL Error 1583 "Sequence metadata could not be updated"
[ https://issues.apache.org/jira/browse/TRAFODION-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek closed TRAFODION-2061. Resolution: Duplicate > SQL Error 1583 "Sequence metadata could not be updated" > --- > > Key: TRAFODION-2061 > URL: https://issues.apache.org/jira/browse/TRAFODION-2061 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: 2.1-incubating > Environment: OS Type and Version: Centos release 6.7 > Trafodion SW Version: 2.1 > CDH Version: 5.5.4 > JDK Version: 1.7.0_67 >Reporter: Jarek > Attachments: > coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log, > coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > > > Issue Description: > When insert data using multi threads program, some insertion data is missing > because of SQL error 1583 "Sequence metadata could not be updated" occurred. > Test Steps: > Step 0. Hive Metastore Server Instance is running. > Step 1. Start multi threads program. > Step 2. Stop Hive Metastore Server Instance. > Step 3. Back to multi threads program, it still running, waiting it completed. > Step 4. Check multi threads program output and the log file. > 1) output is, > DEBUG: plan to delete total rows is 291488 > DEBUG: remaining rows to delete is 291400 > DEBUG: Remaining rows 310909 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 88 > DEBUG: Missing insertion rows 3# please note that here 3 is > not fixed, if you run several times, it will be changed other number. > Total Tests=1 Failed=1 > 2) log file attached, > "coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" > 13:46:52 ***ERROR: SQLExecDirect: Expected: SQL_SUCCESS Actual: SQL_ERROR >File: ../../../../src/coast/coast_unified/src/jmtload.c Line: 187 > # please note that here 187 line is used to insert a row > into table >State: X01G7 >Native Error: 4294965713 >Error: [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** > ERROR[1583] Sequence metadata could not be updated. [2016-06-07 13:46:52] > By the way, if skip step 3, no this kind error occurred, the output and log > file below, > 1) output is, > DEBUG: plan to delete total rows is 145895 > DEBUG: remaining rows to delete is 145809 > DEBUG: Remaining rows 310914 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 86 > DEBUG: Missing insertion rows 0 > Total Tests=1 Failed=0 > 2) log file attached, > "coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRAFODION-2061) SQL Error 1583 "Sequence metadata could not be updated"
[ https://issues.apache.org/jira/browse/TRAFODION-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek updated TRAFODION-2061: - Attachment: coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > SQL Error 1583 "Sequence metadata could not be updated" > --- > > Key: TRAFODION-2061 > URL: https://issues.apache.org/jira/browse/TRAFODION-2061 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: 2.1-incubating > Environment: OS Type and Version: Centos release 6.7 > Trafodion SW Version: 2.1 > CDH Version: 5.5.4 > JDK Version: 1.7.0_67 >Reporter: Jarek > Attachments: > coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log, > coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log > > > Issue Description: > When insert data using multi threads program, some insertion data is missing > because of SQL error 1583 "Sequence metadata could not be updated" occurred. > Test Steps: > Step 0. Hive Metastore Server Instance is running. > Step 1. Start multi threads program. > Step 2. Stop Hive Metastore Server Instance. > Step 3. Back to multi threads program, it still running, waiting it completed. > Step 4. Check multi threads program output and the log file. > 1) output is, > DEBUG: plan to delete total rows is 291488 > DEBUG: remaining rows to delete is 291400 > DEBUG: Remaining rows 310909 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 88 > DEBUG: Missing insertion rows 3# please note that here 3 is > not fixed, if you run several times, it will be changed other number. > Total Tests=1 Failed=1 > 2) log file attached, > "coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" > 13:46:52 ***ERROR: SQLExecDirect: Expected: SQL_SUCCESS Actual: SQL_ERROR >File: ../../../../src/coast/coast_unified/src/jmtload.c Line: 187 > # please note that here 187 line is used to insert a row > into table >State: X01G7 >Native Error: 4294965713 >Error: [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** > ERROR[1583] Sequence metadata could not be updated. [2016-06-07 13:46:52] > By the way, if skip step 3, no this kind error occurred, the output and log > file below, > 1) output is, > DEBUG: plan to delete total rows is 145895 > DEBUG: remaining rows to delete is 145809 > DEBUG: Remaining rows 310914 > DEBUG: Total rows 311000 > DEBUG: Deleted rows 86 > DEBUG: Missing insertion rows 0 > Total Tests=1 Failed=0 > 2) log file attached, > "coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TRAFODION-2061) SQL Error 1583 "Sequence metadata could not be updated"
Jarek created TRAFODION-2061: Summary: SQL Error 1583 "Sequence metadata could not be updated" Key: TRAFODION-2061 URL: https://issues.apache.org/jira/browse/TRAFODION-2061 Project: Apache Trafodion Issue Type: Bug Components: sql-general Affects Versions: 2.1-incubating Environment: OS Type and Version: Centos release 6.7 Trafodion SW Version: 2.1 CDH Version: 5.5.4 JDK Version: 1.7.0_67 Reporter: Jarek Issue Description: When insert data using multi threads program, some insertion data is missing because of SQL error 1583 "Sequence metadata could not be updated" occurred. Test Steps: Step 0. Hive Metastore Server Instance is running. Step 1. Start multi threads program. Step 2. Stop Hive Metastore Server Instance. Step 3. Back to multi threads program, it still running, waiting it completed. Step 4. Check multi threads program output and the log file. 1) output is, DEBUG: plan to delete total rows is 291488 DEBUG: remaining rows to delete is 291400 DEBUG: Remaining rows 310909 DEBUG: Total rows 311000 DEBUG: Deleted rows 88 DEBUG: Missing insertion rows 3# please note that here 3 is not fixed, if you run several times, it will be changed other number. Total Tests=1 Failed=1 2) log file attached, "coast_2016-06-07_13.43.58.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" 13:46:52 ***ERROR: SQLExecDirect: Expected: SQL_SUCCESS Actual: SQL_ERROR File: ../../../../src/coast/coast_unified/src/jmtload.c Line: 187 # please note that here 187 line is used to insert a row into table State: X01G7 Native Error: 4294965713 Error: [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[1583] Sequence metadata could not be updated. [2016-06-07 13:46:52] By the way, if skip step 3, no this kind error occurred, the output and log file below, 1) output is, DEBUG: plan to delete total rows is 145895 DEBUG: remaining rows to delete is 145809 DEBUG: Remaining rows 310914 DEBUG: Total rows 311000 DEBUG: Deleted rows 86 DEBUG: Missing insertion rows 0 Total Tests=1 Failed=0 2) log file attached, "coast_2016-06-07_13.53.49.ANSI.GBK.MultiThread.linux64.TRAF_GBK.log" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
