[jira] [Created] (TRAFODION-2854) Load encounter Operating system error 201
Selvaganesan Govindarajan created TRAFODION-2854: Summary: Load encounter Operating system error 201 Key: TRAFODION-2854 URL: https://issues.apache.org/jira/browse/TRAFODION-2854 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating Load data from hive data encounter 201 error, but using uspert using load the error is different >>load with log error rows to '/bulkload/logs' into >>TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from >>hive.hive.DM_FUNCTION_LOCATION; Task: LOAD Status: Started Object: TRAFODION.ODS_SC.DM_FUNCTION_LOCATION Task: CLEANUP Status: Started Time: 2017-12-15 10:04:17.366 Task: CLEANUP Status: Ended Time: 2017-12-15 10:04:17.385 Task: CLEANUP Status: Ended Elapsed Time: 00:00:00.019 Logging Location: /bulkload/logs/ERR_TRAFODION.ODS_SC.DM_FUNCTION_LOCATION_20171215_020417 Task: LOADING DATA Status: Started Time: 2017-12-15 10:04:17.385 *** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526. *** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526. *** ERROR[2034] $Z000RN4:502: Operating system error 201 while communicating with server process $Z0211QE:526. SQL>upsert using load into TRAFODION.ODS_SC.DM_FUNCTION_LOCATION select * from hive.hive.DM_FUNCTION_LOCATION; *** ERROR[8411] A numeric overflow occurred during an arithmetic computation or data conversion. Conversion of Source Type:CHAR(REC_BYTE_F_ASCII,15 BYTES,ISO88591) Source Value:214040391595900 to Target Type:DECIMAL SIGNED(REC_DECIMAL_LSE). [2017-12-15 13:46:59] Additional Information Core file and stack trace are under 10.10.22.152:/opt/GuangXi_20171218 Account: root/linux Step to analyze core: [root@esggy-del-n002 GuangXi_20171218]# gdb (gdb) source zgdb-GuangXi_20171218- (gdb) file /opt/esgynDB223/export/bin64/tdm_arkesp (gdb) core core.44989 (gdb) bt #0 0x7f440e0ea1d7 in raise () from /opt/GuangXi_20171218/lib64/libc.so.6 #1 0x7f440e0eb8c8 in abort () from /opt/GuangXi_20171218/lib64/libc.so.6 #2 0x7f4410039f85 in os::abort(bool) () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so #3 0x7f44101dc383 in VMError::report_and_die() () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so 004 0x7f441003f48f in JVM_handle_linux_signal () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so 005 0x7f44100359d3 in signalHandler(int, siginfo*, void*) () from /opt/GuangXi_20171218/opt/jdk1.8.0_112/jre/lib/amd64/server/libjvm.so 006 007 0x7f440e1ffde0 in __memcpy_ssse3_back () from /opt/GuangXi_20171218/lib64/libc.so.6 008 0x7f441308aeaf in str_cpy_all (length=-7167, src=, tgt=0x7fff64f1ed60 "\200") at ../common/str.h:265 009 getLength (data=, this=0x80) at ../exp/exp_attrs.h:415 010 ExHbaseAccessBulkLoadPrepSQTcb::createLoggingRow (this=, tuppIndex=, tuppRow=0x7f43fe67e3d0 "", targetRow=0x7f43fe68e401 "", targetRowLen=@0x7fff64f1eea0: 0) at ../executor/ExHbaseIUD.cpp:1754 011 0x7f441308ed1c in ExHbaseAccessBulkLoadPrepSQTcb::work (this=0x7f43fe662f48) at ../executor/ExHbaseIUD.cpp:1591 012 0x7f441309b46f in donotUpdateCounters (this=0x1343d9928) at ../executor/ExStats.h:3729 013 ExScheduler::work (this=0x7f44141a2008, prevWaitTime=) at ../executor/ExScheduler.cpp:296 014 0x7f4412fc69ed in ExEspFragInstanceDir::fixupEntry (this=0x0, handle=320060680, numOfParentInstances=1693577552, da=...) at ../executor/ex_esp_frag_dir.cpp:331 015 0x0040ca26 in runESP (argc=argc@entry=3, argv=argv@entry=0x7fff64f1f878, guaReceiveFastStart=guaReceiveFastStart@entry=0x0) at ../bin/ex_esp_main.cpp:404 016 0x0040bd9b in main (argc=3, argv=0x7fff64f1f878) at ../bin/ex_esp_main.cpp:258 (gdb) This issue was observed at a customer installation that deployed EsgynDB -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2853) Memory leak of ComDiagsArea in Context
Selvaganesan Govindarajan created TRAFODION-2853:
Summary: Memory leak of ComDiagsArea in Context
Key: TRAFODION-2853
URL: https://issues.apache.org/jira/browse/TRAFODION-2853
Project: Apache Trafodion
Issue Type: Bug
Components: sql-exe
Affects Versions: any
Reporter: Selvaganesan Govindarajan
Assignee: Selvaganesan Govindarajan
Fix For: 2.3-incubating
There were instances that the executor master process has more than 1 GB of
memory account memory allocated, Looking at the size of allocation by
traversing the heap, it was found ComDiagsArea is leaked in ContextHeap.
The heap traversal shows the addresses and the allocated size that were part of
context Heap that was leaking
0x7fdef4cc69b8 336
0x7fdef4cc6bc8 336
0x7fdef4cc6d18 336
0x7fdef4cc6e68 336
0x7fdef4cc6fb8 336
0x7fdef4cc71e0 336
0x7fdef4cc7330 336
0x7fdef4cc7480 336
The actual address of the objects is 16 bytes from the above address
(gdb) p *(ComDiagsArea *)0x7fdef4cc69c8
$9 = {
= {
_vptr.IpcMessageObj = 0x7fdfbe4bbc50,
s_ = {
objType_ = 13501,
objVersion_ = 0,
refCount_ = 1,
objLength_ = 0,
next_ = 0x0,
endianness_ = 1 '\001',
spare1_ = 0 '\000',
spare2_ = 0,
vPtrPad_ = 0x0
}
},
members of ComDiagsArea:
collHeapPtr_ = 0x7fdfb18eb128,
errors_ = {
> = {
= {
_vptr.NABasicObject = 0x7fdfbe4bbf10,
h_ = 0x0
},
members of NACollection:
maxLength_ = 0,
usedLength_ = 0,
entries_ = 0,
arr_ = 0x0,
usages_ = 0x0,
heap_ = 0x7fdfb18eb128
},
members of NAList:
first_ = 1,
last_ = 1,
userIndexCache_ = 1,
arrayIndexCache_ = 1
},
warnings_ = {
---Type to continue, or q to quit---
> = {
= {
_vptr.NABasicObject = 0x7fdfbe4bbf10,
h_ = 0x0
},
members of NACollection:
maxLength_ = 0,
usedLength_ = 0,
entries_ = 0,
arr_ = 0x0,
usages_ = 0x0,
heap_ = 0x7fdfb18eb128
},
members of NAList:
first_ = 1,
last_ = 1,
userIndexCache_ = 1,
arrayIndexCache_ = 1
},
newCondition_ = 0x0,
areMore_ = 0,
lengthLimit_ = 30,
rowCount_ = 0,
theSQLFunction_ = 0,
maxDiagsId_ = 0,
avgStreamWaitTime_ = -1,
cost_ = 0,
flags_ = 0,
rowsetRowCountArray_ = 0x0,
fillers_ = '\000'
}
(gdb) (gdb) p *(NAHeap *)0x7fdfb18eb128
$10 = {
= {
= {
_vptr.NABasicObject = 0x7fdfc1001870,
h_ = 0x0
},
members of NAMemory:
name_ = "Heap in ContextCli\000\000",
type_ = NAMemory::DERIVED_MEMORY,
initialSize_ = 524288,
maximumSize_ = 18446744073709551615,
incrementSize_ = 4194304,
parent_ = 0xf18b38,
firstBlk_ = 0x7f3a44f75030,
allocSize_ = 1375405192,
upperLimit_ = 0,
highWaterMark_ = 1447646816,
intervalWaterMark_ = 1447646816,
allocCnt_ = 2837663,
totalSize_ = 1529356096,
blockCnt_ = 381,
thBlockCnt_ = 40,
segGlobals_ = 0x0,
memoryList_ = 0x7fdfb0e7aac0,
lastListEntry_ = 0x7fdeef140608,
nextEntry_ = 0x7fdfb18f12c8,
debugLevel_ = 0,
heapJumpBuf_ = 0xf18a30,
exhaustedMem_ = 0,
errorsMask_ = 0,
heapID_ = {
heapNum = -1
},
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TRAFODION-2836) Enable Trafodion SQL processes to configure garbage collector in its embedded JVM
Selvaganesan Govindarajan created TRAFODION-2836: Summary: Enable Trafodion SQL processes to configure garbage collector in its embedded JVM Key: TRAFODION-2836 URL: https://issues.apache.org/jira/browse/TRAFODION-2836 Project: Apache Trafodion Issue Type: Improvement Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Priority: Minor Fix For: 2.3-incubating This allows Trafodion SQL processes to choose the best garbage collection especially in a multi-threaded environment. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2821) Trafodion core code base needs to be thread safe
Selvaganesan Govindarajan created TRAFODION-2821: Summary: Trafodion core code base needs to be thread safe Key: TRAFODION-2821 URL: https://issues.apache.org/jira/browse/TRAFODION-2821 Project: Apache Trafodion Issue Type: Improvement Components: sql-general Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating This is the covering trafodion jira to make trafodion core code base to be thread safe. It is needed to ensure that type T2 JDBC driver hosted on platform can be enabled to support multi-threaded JDBC applications. [TRAFODION-2783] is one such case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2801) select count(*) with cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest' fail
[ https://issues.apache.org/jira/browse/TRAFODION-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16246597#comment-16246597 ] Selvaganesan Govindarajan commented on TRAFODION-2801: -- [~suresh_subbiah] analyzed the core file and found the following The columnName we got from previous getColName method is junk, though length is correct (it is 4) Debugging the Java side and see that for the specified offsets, value is junk on Java side too. Actual column name is present in Cell, but at a different offset. >From what I can tell, the problem seems to be that we are using the offset >obtained from getFamilyOffset(), and using it to read bytes from the byte[] >getValueArray(). However the API suggests that getFamilyOffset() should be >used as an offset into getFamilyArray() and NOT into getValueArray(). The two >may coincide but it is not guaranteed. > select count(*) with cqd hbase_coprocessors 'off' and cqd > traf_table_snapshot_scan 'latest' fail > > > Key: TRAFODION-2801 > URL: https://issues.apache.org/jira/browse/TRAFODION-2801 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > WHile using cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan > 'latest', > count( * ) of a table fail, error below, > SQL>select count ( * ) from ry_hcyxx_32; > *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating > with server process $Z01198S:62. [2017-07-20 11:01:27] > *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating > with server process $Z01198S:62. [2017-07-20 11:01:27] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TRAFODION-2801) select count(*) with cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest' fail
[ https://issues.apache.org/jira/browse/TRAFODION-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2801: - Description: WHile using cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest', count( * ) of a table fail, error below, SQL>select count ( * ) from ry_hcyxx_32; *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] was: WHile using cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest', count(*) of a table fail, error below, SQL>select count(*) from ry_hcyxx_32; *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] > select count(*) with cqd hbase_coprocessors 'off' and cqd > traf_table_snapshot_scan 'latest' fail > > > Key: TRAFODION-2801 > URL: https://issues.apache.org/jira/browse/TRAFODION-2801 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > WHile using cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan > 'latest', > count( * ) of a table fail, error below, > SQL>select count ( * ) from ry_hcyxx_32; > *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating > with server process $Z01198S:62. [2017-07-20 11:01:27] > *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating > with server process $Z01198S:62. [2017-07-20 11:01:27] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2801) select count(*) with cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest' fail
Selvaganesan Govindarajan created TRAFODION-2801: Summary: select count(*) with cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest' fail Key: TRAFODION-2801 URL: https://issues.apache.org/jira/browse/TRAFODION-2801 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating WHile using cqd hbase_coprocessors 'off' and cqd traf_table_snapshot_scan 'latest', count(*) of a table fail, error below, SQL>select count(*) from ry_hcyxx_32; *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] *** ERROR[2034] $Z020RPF:33: Operating system error 201 while communicating with server process $Z01198S:62. [2017-07-20 11:01:27] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2783) jdbc_test_cdh fails at times with type 2 JDBC driver dumping core
[ https://issues.apache.org/jira/browse/TRAFODION-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2783. -- Resolution: Fixed https://github.com/apache/incubator-trafodion/pull/1277 > jdbc_test_cdh fails at times with type 2 JDBC driver dumping core > - > > Key: TRAFODION-2783 > URL: https://issues.apache.org/jira/browse/TRAFODION-2783 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the core is > Thread 1 (Thread 0x7fad11e95700 (LWP 38697)): > #0 0x7fad110a95f7 in raise () from /lib64/libc.so.6 > #1 0x7fad110aace8 in abort () from /lib64/libc.so.6 > 2 0x7fad0fecb9d5 in __gnu_cxx::__verbose_terminate_handler() () from > /lib64/libstdc++.so.6 > #3 0x7fad0fec9946 in ?? () from /lib64/libstdc++.so.6 > #4 0x7fad0fec9973 in std::terminate() () from /lib64/libstdc++.so.6 > #5 0x7fad0feca4df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 > #6 0x7fad109ebc76 in outputStream::print_cr(char const*, ...) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #7 0x7fad10b7ca07 in VMError::report(outputStream*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #8 0x7fad10b7e69f in VMError::report_and_die() () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #9 0x7fad109e85c7 in JVM_handle_linux_signal () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #10 0x7fad109dc848 in signalHandler(int, siginfo_t*, void*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #11 > #12 0x7facf1afbfad in NACollection::constEntry > (this=0x7facf1f25440 , ix=0) at > ../common/Collections.h:410 > #13 0x7facf1afb786 in NAList::operator[] > (this=0x7facf1f25440 , i=0) at > ../common/Collections.cpp:924 > #14 0x7facf1afb014 in NAList::at > (this=0x7facf1f25440 , i=0) at > ../common/Collections.h:2058 > #15 0x7facf1afa2be in CollationDB::getCollationInfo (this=0x7facf1f25440 > , co=CharInfo::DefaultCollation) at > ../common/charinfo.cpp:455 > #16 0x7facf1afa34f in CollationDB::getCollationName (this=0x7facf1f25440 > , co=CharInfo::DefaultCollation, > retUnknownAsBlank=0) at ../common/charinfo.cpp:466 > #17 0x7facf1afa649 in CharInfo::getCollationName > (co=CharInfo::DefaultCollation, retUnknownAsBlank=0) at > ../common/charinfo.cpp:584 > #18 0x7facf1b7ecad in NAType::convertTypeToText (text=0x7fad11e8e6c0 "INT > UNSIGNED", fs_datatype=0, length=60, precision=0, scale=0, > datetimestart=REC_DATE_UNKNOWN, datetimeend=REC_DATE_UNKNOWN, > datetimefractprec=0, intervalleadingprec=0, upshift=0, caseinsensitive=0, > charSet=CharInfo::ISO88591, collation=CharInfo::DefaultCollation, > displaydatatype=0x0, displayCaseSpecific=0) at ../common/NAType.cpp:693 > #19 0x7face933bc7a in Generator::createColDescs (tableName=0x7facea48af18 > "EXPLAIN__", columnInfo=0x7face97d4c00 , > numCols=14, offset=@0x7fad11e8e8c4: 66, space=0x0) at > ../generator/Generator.cpp:1444 > #20 0x7face93784ff in ExplainFunc::createVirtualTableDesc > (this=0x7fad11e8ec90) at ../generator/GenExplain.cpp:2233 > #21 0x7face944b484 in RelRoot::codeGen (this=0x7facd61a7a50, > generator=0x7fad11e90c60) at ../generator/GenRelMisc.cpp:1226 > #22 0x7face9339d6b in Generator::genCode (this=0x7fad11e90c60, > source=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where > CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = > 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", > expr_node=0x7facd61a7a50) at ../generator/Generator.cpp:577 > #23 0x7facebe6763b in CmpMain::compile (this=0x7fad11e92d60, > input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where > CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = > 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", charset=15, > queryExpr=@0x7fad11e92bb8: 0x7facd61a7a50, gen_code=0x7facd9cda718, > gen_code_len=0x7facd9cda710, heap=0x7facdfab40b8, phase=CmpMain::END, > fragmentDir=0x7fad11e92df0, op=3004, useQueryCache=CmpMain::NORMAL, > cacheable=0x7fad11e92ba4, begTime=0x7fad11e92bc0, shouldLog=0) at > ../sqlcomp/CmpMain.cpp:2453 > #24 0x7facebe65170 in CmpMain::sqlcomp (this=0x7fad11e92d60, > input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where > CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME =
[jira] [Resolved] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[ https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2785. -- Resolution: Fixed https://github.com/apache/incubator-trafodion/pull/1280 > mxosrvr dumps core generated when loading data from Oracle to Trafodion at > times > > > Key: TRAFODION-2785 > URL: https://issues.apache.org/jira/browse/TRAFODION-2785 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the dump is > #0 0x7feb0d59f5f7 in raise () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #1 0x7feb0d5a0e28 in abort () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #2 0x7feb0eea7f85 in os::abort(bool) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #3 0x7feb0f04a383 in VMError::report_and_die() () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #4 0x7feb0eead48f in JVM_handle_linux_signal () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #6 > #7 0x7feb0a00e833 in convCharToChar (source=, > sourceLen=, sourceType=, sourcePrecision=256, > sourceScale=, > target=0x7feacb882bcc '\377' , targetLen=1717986918, > targetType=26214, targetPrecision=1717986918, targetScale=1717986918, > heap=0x, > diagsArea=0x, dataConversionErrorFlag=0x, > actualTargetLen=0x, blankPadResult=0, > ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0) > at ../exp/exp_conv.cpp:4895 > #8 0x in ?? () > #9 0x in ?? () > #10 0x in ?? () > #11 0x in ?? () > #12 0x in ?? () > #13 0x in ?? () > #14 0x in ?? () > #15 0x in ?? () > #16 0x in ?? () > #17 0x in ?? () -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[ https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16225797#comment-16225797 ] Selvaganesan Govindarajan commented on TRAFODION-2785: -- It is found that the corruption happens in RH7 > mxosrvr dumps core generated when loading data from Oracle to Trafodion at > times > > > Key: TRAFODION-2785 > URL: https://issues.apache.org/jira/browse/TRAFODION-2785 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the dump is > #0 0x7feb0d59f5f7 in raise () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #1 0x7feb0d5a0e28 in abort () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #2 0x7feb0eea7f85 in os::abort(bool) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #3 0x7feb0f04a383 in VMError::report_and_die() () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #4 0x7feb0eead48f in JVM_handle_linux_signal () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #6 > #7 0x7feb0a00e833 in convCharToChar (source=, > sourceLen=, sourceType=, sourcePrecision=256, > sourceScale=, > target=0x7feacb882bcc '\377' , targetLen=1717986918, > targetType=26214, targetPrecision=1717986918, targetScale=1717986918, > heap=0x, > diagsArea=0x, dataConversionErrorFlag=0x, > actualTargetLen=0x, blankPadResult=0, > ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0) > at ../exp/exp_conv.cpp:4895 > #8 0x in ?? () > #9 0x in ?? () > #10 0x in ?? () > #11 0x in ?? () > #12 0x in ?? () > #13 0x in ?? () > #14 0x in ?? () > #15 0x in ?? () > #16 0x in ?? () > #17 0x in ?? () -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[ https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223074#comment-16223074 ] Selvaganesan Govindarajan edited comment on TRAFODION-2785 at 10/28/17 12:09 AM: - So, it is quite clear from the above hextostring caused buffer overrun and hence corrupted the stack was (Author: selvag): So, it is quite clear from the above hextostring caused buffer overrun and hence corrupted the stack trace > mxosrvr dumps core generated when loading data from Oracle to Trafodion at > times > > > Key: TRAFODION-2785 > URL: https://issues.apache.org/jira/browse/TRAFODION-2785 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the dump is > #0 0x7feb0d59f5f7 in raise () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #1 0x7feb0d5a0e28 in abort () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #2 0x7feb0eea7f85 in os::abort(bool) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #3 0x7feb0f04a383 in VMError::report_and_die() () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #4 0x7feb0eead48f in JVM_handle_linux_signal () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #6 > #7 0x7feb0a00e833 in convCharToChar (source=, > sourceLen=, sourceType=, sourcePrecision=256, > sourceScale=, > target=0x7feacb882bcc '\377' , targetLen=1717986918, > targetType=26214, targetPrecision=1717986918, targetScale=1717986918, > heap=0x, > diagsArea=0x, dataConversionErrorFlag=0x, > actualTargetLen=0x, blankPadResult=0, > ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0) > at ../exp/exp_conv.cpp:4895 > #8 0x in ?? () > #9 0x in ?? () > #10 0x in ?? () > #11 0x in ?? () > #12 0x in ?? () > #13 0x in ?? () > #14 0x in ?? () > #15 0x in ?? () > #16 0x in ?? () > #17 0x in ?? () -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[ https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223074#comment-16223074 ] Selvaganesan Govindarajan commented on TRAFODION-2785: -- So, it is quite clear from the above hextostring caused buffer overrun and hence corrupted the stack trace > mxosrvr dumps core generated when loading data from Oracle to Trafodion at > times > > > Key: TRAFODION-2785 > URL: https://issues.apache.org/jira/browse/TRAFODION-2785 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the dump is > #0 0x7feb0d59f5f7 in raise () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #1 0x7feb0d5a0e28 in abort () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 > #2 0x7feb0eea7f85 in os::abort(bool) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #3 0x7feb0f04a383 in VMError::report_and_die() () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #4 0x7feb0eead48f in JVM_handle_linux_signal () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from > /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so > #6 > #7 0x7feb0a00e833 in convCharToChar (source=, > sourceLen=, sourceType=, sourcePrecision=256, > sourceScale=, > target=0x7feacb882bcc '\377' , targetLen=1717986918, > targetType=26214, targetPrecision=1717986918, targetScale=1717986918, > heap=0x, > diagsArea=0x, dataConversionErrorFlag=0x, > actualTargetLen=0x, blankPadResult=0, > ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0) > at ../exp/exp_conv.cpp:4895 > #8 0x in ?? () > #9 0x in ?? () > #10 0x in ?? () > #11 0x in ?? () > #12 0x in ?? () > #13 0x in ?? () > #14 0x in ?? () > #15 0x in ?? () > #16 0x in ?? () > #17 0x in ?? () -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[
https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223069#comment-16223069
]
Selvaganesan Govindarajan edited comment on TRAFODION-2785 at 10/28/17 12:07 AM:
-
Reconstruct the stack from the variables, the stack had the following variables
p = (char **) 0x7feafab02868
p = (UInt32 *) 0x7feafab02870
p = (UInt32 *) 0x7feafab02874
p = (char **) 0x7feafab02878
Gap in the stack
p ((char (*)[256]) 0x7feafab028b0
p = (char (*)[512]) 0x7feafab029b0
Upto 0x7feafab02bb0
p = (Lng32 *) 0x7feafab02bf0
(gdb) x /100x 0x7feafab02868
0x7feafab02868: 0x7feacb882bcc 0x
0x7feafab02878: 0x{color:red} 0x7feb0ce16290{color}
0x7feafab02888: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162b0{color}
0x7feafab02898: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162d0{color}
0x7feafab028a8: 0x7feafab028b0 0x
0x7feafab028b8: 0x 0x
0x7feafab028c8: 0x 0x
0x7feafab028d8: 0x 0x
The addresses in {color:red}red {color} are the parameters to ComDiagsArea and
DgString0 and DgString1 and DgString2 inline functions respectively
was (Author: selvag):
Reconstruct the stack from the variables, the stack had the following variables
p = (char **) 0x7feafab02868
p = (UInt32 *) 0x7feafab02870
p = (UInt32 *) 0x7feafab02874
p = (char **) 0x7feafab02878
Gap in the stack
p ((char (*)[256]) 0x7feafab028b0
p = (char (*)[512]) 0x7feafab029b0
Upto 0x7feafab02bb0
p = (Lng32 *) 0x7feafab02bf0
(gdb) x /100x 0x7feafab02868
0x7feafab02868: 0x7feacb882bcc 0x
0x7feafab02878: 0x{color:red} 0x7feb0ce16290{color}
0x7feafab02888: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162b0{color}
0x7feafab02898: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162d0{color}
0x7feafab028a8: 0x7feafab028b0 0x
0x7feafab028b8: 0x 0x
0x7feafab028c8: 0x 0x
0x7feafab028d8: 0x 0x
These are the parameters to ComDiagsArea and DgString0 and DgString1 and
DgString2 inline functions respectively
> mxosrvr dumps core generated when loading data from Oracle to Trafodion at
> times
>
>
> Key: TRAFODION-2785
> URL: https://issues.apache.org/jira/browse/TRAFODION-2785
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.3-incubating
>
>
> The stack trace of the dump is
> #0 0x7feb0d59f5f7 in raise () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #1 0x7feb0d5a0e28 in abort () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #2 0x7feb0eea7f85 in os::abort(bool) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #3 0x7feb0f04a383 in VMError::report_and_die() () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #4 0x7feb0eead48f in JVM_handle_linux_signal () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #6
> #7 0x7feb0a00e833 in convCharToChar (source=,
> sourceLen=, sourceType=, sourcePrecision=256,
> sourceScale=,
> target=0x7feacb882bcc '\377' , targetLen=1717986918,
> targetType=26214, targetPrecision=1717986918, targetScale=1717986918,
> heap=0x,
> diagsArea=0x, dataConversionErrorFlag=0x,
> actualTargetLen=0x, blankPadResult=0,
> ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0)
> at ../exp/exp_conv.cpp:4895
> #8 0x in ?? ()
> #9 0x in ?? ()
> #10 0x in ?? ()
> #11 0x in ?? ()
> #12 0x in ?? ()
> #13 0x in ?? ()
> #14 0x in ?? ()
> #15 0x in ?? ()
> #16 0x in ?? ()
> #17 0x in ?? ()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[
https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223069#comment-16223069
]
Selvaganesan Govindarajan edited comment on TRAFODION-2785 at 10/28/17 12:06 AM:
-
Reconstruct the stack from the variables, the stack had the following variables
p = (char **) 0x7feafab02868
p = (UInt32 *) 0x7feafab02870
p = (UInt32 *) 0x7feafab02874
p = (char **) 0x7feafab02878
Gap in the stack
p ((char (*)[256]) 0x7feafab028b0
p = (char (*)[512]) 0x7feafab029b0
Upto 0x7feafab02bb0
p = (Lng32 *) 0x7feafab02bf0
(gdb) x /100x 0x7feafab02868
0x7feafab02868: 0x7feacb882bcc 0x
0x7feafab02878: 0x{color:red} 0x7feb0ce16290{color}
0x7feafab02888: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162b0{color}
0x7feafab02898: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162d0{color}
0x7feafab028a8: 0x7feafab028b0 0x
0x7feafab028b8: 0x 0x
0x7feafab028c8: 0x 0x
0x7feafab028d8: 0x 0x
These are the parameters to ComDiagsArea and DgString0 and DgString1 and
DgString2 inline functions respectively
was (Author: selvag):
Reconstruct the stack from the variables, the stack had the following variables
p = (char **) 0x7feafab02868
p = (UInt32 *) 0x7feafab02870
p = (UInt32 *) 0x7feafab02874
p = (char **) 0x7feafab02878
Gap in the stack
p ((char (*)[256]) 0x7feafab028b0
p = (char (*)[512]) 0x7feafab029b0
Upto 0x7feafab02bb0
p = (Lng32 *) 0x7feafab02bf0
(gdb) x /100x 0x7feafab02868
0x7feafab02868: 0x7feacb882bcc 0x
0x7feafab02878: 0x{color:red} 0x7feb0ce16290{color}
0x7feafab02888: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162b0{color}
0x7feafab02898: {color:red}0x7feb0ab8c5b0{color}
0{color:red}x7feb0ce162d0{color}
0x7feafab028a8: 0x7feafab028b0 0x
0x7feafab028b8: 0x 0x
0x7feafab028c8: 0x 0x
0x7feafab028d8: 0x 0x
> mxosrvr dumps core generated when loading data from Oracle to Trafodion at
> times
>
>
> Key: TRAFODION-2785
> URL: https://issues.apache.org/jira/browse/TRAFODION-2785
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.3-incubating
>
>
> The stack trace of the dump is
> #0 0x7feb0d59f5f7 in raise () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #1 0x7feb0d5a0e28 in abort () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #2 0x7feb0eea7f85 in os::abort(bool) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #3 0x7feb0f04a383 in VMError::report_and_die() () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #4 0x7feb0eead48f in JVM_handle_linux_signal () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #6
> #7 0x7feb0a00e833 in convCharToChar (source=,
> sourceLen=, sourceType=, sourcePrecision=256,
> sourceScale=,
> target=0x7feacb882bcc '\377' , targetLen=1717986918,
> targetType=26214, targetPrecision=1717986918, targetScale=1717986918,
> heap=0x,
> diagsArea=0x, dataConversionErrorFlag=0x,
> actualTargetLen=0x, blankPadResult=0,
> ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0)
> at ../exp/exp_conv.cpp:4895
> #8 0x in ?? ()
> #9 0x in ?? ()
> #10 0x in ?? ()
> #11 0x in ?? ()
> #12 0x in ?? ()
> #13 0x in ?? ()
> #14 0x in ?? ()
> #15 0x in ?? ()
> #16 0x in ?? ()
> #17 0x in ?? ()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
[
https://issues.apache.org/jira/browse/TRAFODION-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16223069#comment-16223069
]
Selvaganesan Govindarajan commented on TRAFODION-2785:
--
Reconstruct the stack from the variables, the stack had the following variables
p = (char **) 0x7feafab02868
p = (UInt32 *) 0x7feafab02870
p = (UInt32 *) 0x7feafab02874
p = (char **) 0x7feafab02878
Gap in the stack
p ((char (*)[256]) 0x7feafab028b0
p = (char (*)[512]) 0x7feafab029b0
Upto 0x7feafab02bb0
p = (Lng32 *) 0x7feafab02bf0
(gdb) x /100x 0x7feafab02868
0x7feafab02868: 0x7feacb882bcc 0x
0x7feafab02878: 0x{color:red} 0x7feb0ce16290{color}
0x7feafab02888: {color:red}0x7feb0ab8c5b0{color}
{color:red}0x7feb0ce162b0{color}
0x7feafab02898: {color:red}0x7feb0ab8c5b0{color}
0{color:red}x7feb0ce162d0{color}
0x7feafab028a8: 0x7feafab028b0 0x
0x7feafab028b8: 0x 0x
0x7feafab028c8: 0x 0x
0x7feafab028d8: 0x 0x
> mxosrvr dumps core generated when loading data from Oracle to Trafodion at
> times
>
>
> Key: TRAFODION-2785
> URL: https://issues.apache.org/jira/browse/TRAFODION-2785
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.3-incubating
>
>
> The stack trace of the dump is
> #0 0x7feb0d59f5f7 in raise () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #1 0x7feb0d5a0e28 in abort () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6
> #2 0x7feb0eea7f85 in os::abort(bool) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #3 0x7feb0f04a383 in VMError::report_and_die() () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #4 0x7feb0eead48f in JVM_handle_linux_signal () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from
> /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so
> #6
> #7 0x7feb0a00e833 in convCharToChar (source=,
> sourceLen=, sourceType=, sourcePrecision=256,
> sourceScale=,
> target=0x7feacb882bcc '\377' , targetLen=1717986918,
> targetType=26214, targetPrecision=1717986918, targetScale=1717986918,
> heap=0x,
> diagsArea=0x, dataConversionErrorFlag=0x,
> actualTargetLen=0x, blankPadResult=0,
> ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0)
> at ../exp/exp_conv.cpp:4895
> #8 0x in ?? ()
> #9 0x in ?? ()
> #10 0x in ?? ()
> #11 0x in ?? ()
> #12 0x in ?? ()
> #13 0x in ?? ()
> #14 0x in ?? ()
> #15 0x in ?? ()
> #16 0x in ?? ()
> #17 0x in ?? ()
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (TRAFODION-2785) mxosrvr dumps core generated when loading data from Oracle to Trafodion at times
Selvaganesan Govindarajan created TRAFODION-2785: Summary: mxosrvr dumps core generated when loading data from Oracle to Trafodion at times Key: TRAFODION-2785 URL: https://issues.apache.org/jira/browse/TRAFODION-2785 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating The stack trace of the dump is #0 0x7feb0d59f5f7 in raise () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 #1 0x7feb0d5a0e28 in abort () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/lib64/libc.so.6 #2 0x7feb0eea7f85 in os::abort(bool) () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so #3 0x7feb0f04a383 in VMError::report_and_die() () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so #4 0x7feb0eead48f in JVM_handle_linux_signal () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so #5 0x7feb0eea39d3 in signalHandler(int, siginfo*, void*) () from /mnt/gselva/guangxi/zlibs-datanode07.hadoop.gxdwdc/opt/java/jdk1.8/jre/lib/amd64/server/libjvm.so #6 #7 0x7feb0a00e833 in convCharToChar (source=, sourceLen=, sourceType=, sourcePrecision=256, sourceScale=, target=0x7feacb882bcc '\377' , targetLen=1717986918, targetType=26214, targetPrecision=1717986918, targetScale=1717986918, heap=0x, diagsArea=0x, dataConversionErrorFlag=0x, actualTargetLen=0x, blankPadResult=0, ignoreTrailingBlanksInSource=1, allowInvalidCodePoint=0) at ../exp/exp_conv.cpp:4895 #8 0x in ?? () #9 0x in ?? () #10 0x in ?? () #11 0x in ?? () #12 0x in ?? () #13 0x in ?? () #14 0x in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2783) jdbc_test_cdh fails at times with type 2 JDBC driver dumping core
[ https://issues.apache.org/jira/browse/TRAFODION-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219964#comment-16219964 ] Selvaganesan Govindarajan commented on TRAFODION-2783: -- In case of Type 2 JDBC driver, the Trafodion SQL engine is a library that is dynamic loaded into the process. Initialization of C++ static objects in the dynamic loaded libraries are supposed to be done before dlopen returns. But the behavior seems to be nondeterministic when there are multiple threads or when there are e dependent static objects (An static object expects another to be initialized before it). I think, the order of the initialization is not guaranteed by the standard. > jdbc_test_cdh fails at times with type 2 JDBC driver dumping core > - > > Key: TRAFODION-2783 > URL: https://issues.apache.org/jira/browse/TRAFODION-2783 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The stack trace of the core is > Thread 1 (Thread 0x7fad11e95700 (LWP 38697)): > #0 0x7fad110a95f7 in raise () from /lib64/libc.so.6 > #1 0x7fad110aace8 in abort () from /lib64/libc.so.6 > 2 0x7fad0fecb9d5 in __gnu_cxx::__verbose_terminate_handler() () from > /lib64/libstdc++.so.6 > #3 0x7fad0fec9946 in ?? () from /lib64/libstdc++.so.6 > #4 0x7fad0fec9973 in std::terminate() () from /lib64/libstdc++.so.6 > #5 0x7fad0feca4df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 > #6 0x7fad109ebc76 in outputStream::print_cr(char const*, ...) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #7 0x7fad10b7ca07 in VMError::report(outputStream*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #8 0x7fad10b7e69f in VMError::report_and_die() () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #9 0x7fad109e85c7 in JVM_handle_linux_signal () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #10 0x7fad109dc848 in signalHandler(int, siginfo_t*, void*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #11 > #12 0x7facf1afbfad in NACollection::constEntry > (this=0x7facf1f25440 , ix=0) at > ../common/Collections.h:410 > #13 0x7facf1afb786 in NAList::operator[] > (this=0x7facf1f25440 , i=0) at > ../common/Collections.cpp:924 > #14 0x7facf1afb014 in NAList::at > (this=0x7facf1f25440 , i=0) at > ../common/Collections.h:2058 > #15 0x7facf1afa2be in CollationDB::getCollationInfo (this=0x7facf1f25440 > , co=CharInfo::DefaultCollation) at > ../common/charinfo.cpp:455 > #16 0x7facf1afa34f in CollationDB::getCollationName (this=0x7facf1f25440 > , co=CharInfo::DefaultCollation, > retUnknownAsBlank=0) at ../common/charinfo.cpp:466 > #17 0x7facf1afa649 in CharInfo::getCollationName > (co=CharInfo::DefaultCollation, retUnknownAsBlank=0) at > ../common/charinfo.cpp:584 > #18 0x7facf1b7ecad in NAType::convertTypeToText (text=0x7fad11e8e6c0 "INT > UNSIGNED", fs_datatype=0, length=60, precision=0, scale=0, > datetimestart=REC_DATE_UNKNOWN, datetimeend=REC_DATE_UNKNOWN, > datetimefractprec=0, intervalleadingprec=0, upshift=0, caseinsensitive=0, > charSet=CharInfo::ISO88591, collation=CharInfo::DefaultCollation, > displaydatatype=0x0, displayCaseSpecific=0) at ../common/NAType.cpp:693 > #19 0x7face933bc7a in Generator::createColDescs (tableName=0x7facea48af18 > "EXPLAIN__", columnInfo=0x7face97d4c00 , > numCols=14, offset=@0x7fad11e8e8c4: 66, space=0x0) at > ../generator/Generator.cpp:1444 > #20 0x7face93784ff in ExplainFunc::createVirtualTableDesc > (this=0x7fad11e8ec90) at ../generator/GenExplain.cpp:2233 > #21 0x7face944b484 in RelRoot::codeGen (this=0x7facd61a7a50, > generator=0x7fad11e90c60) at ../generator/GenRelMisc.cpp:1226 > #22 0x7face9339d6b in Generator::genCode (this=0x7fad11e90c60, > source=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where > CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = > 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", > expr_node=0x7facd61a7a50) at ../generator/Generator.cpp:577 > #23 0x7facebe6763b in CmpMain::compile (this=0x7fad11e92d60, > input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where > CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = > 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", charset=15, > queryExpr=@0x7fad11e92bb8: 0x7facd61a7a50,
[jira] [Commented] (TRAFODION-2783) jdbc_test_cdh fails at times with type 2 JDBC driver dumping core
[
https://issues.apache.org/jira/browse/TRAFODION-2783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16219955#comment-16219955
]
Selvaganesan Govindarajan commented on TRAFODION-2783:
--
The static variable CharInfo::builtinCollationDB_ is not initialized fully.
Hence it dumps when this variable is accessed
gdb) p *this
$2 = {
= {
_vptr.NABasicObject = 0x7facf24538f0 ,
h_ = 0x0
},
members of NACollection:
maxLength_ = 7,
usedLength_ = 4,
entries_ = 4,
arr_ = 0x0,
usages_ = 0x0,
heap_ = 0x0
}
> jdbc_test_cdh fails at times with type 2 JDBC driver dumping core
> -
>
> Key: TRAFODION-2783
> URL: https://issues.apache.org/jira/browse/TRAFODION-2783
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-general
>Affects Versions: any
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
> Fix For: 2.3-incubating
>
>
> The stack trace of the core is
> Thread 1 (Thread 0x7fad11e95700 (LWP 38697)):
> #0 0x7fad110a95f7 in raise () from /lib64/libc.so.6
> #1 0x7fad110aace8 in abort () from /lib64/libc.so.6
> 2 0x7fad0fecb9d5 in __gnu_cxx::__verbose_terminate_handler() () from
> /lib64/libstdc++.so.6
> #3 0x7fad0fec9946 in ?? () from /lib64/libstdc++.so.6
> #4 0x7fad0fec9973 in std::terminate() () from /lib64/libstdc++.so.6
> #5 0x7fad0feca4df in __cxa_pure_virtual () from /lib64/libstdc++.so.6
> #6 0x7fad109ebc76 in outputStream::print_cr(char const*, ...) () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so
> #7 0x7fad10b7ca07 in VMError::report(outputStream*) () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so
> #8 0x7fad10b7e69f in VMError::report_and_die() () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so
> #9 0x7fad109e85c7 in JVM_handle_linux_signal () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so
> #10 0x7fad109dc848 in signalHandler(int, siginfo_t*, void*) () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so
> #11
> #12 0x7facf1afbfad in NACollection::constEntry
> (this=0x7facf1f25440 , ix=0) at
> ../common/Collections.h:410
> #13 0x7facf1afb786 in NAList::operator[]
> (this=0x7facf1f25440 , i=0) at
> ../common/Collections.cpp:924
> #14 0x7facf1afb014 in NAList::at
> (this=0x7facf1f25440 , i=0) at
> ../common/Collections.h:2058
> #15 0x7facf1afa2be in CollationDB::getCollationInfo (this=0x7facf1f25440
> , co=CharInfo::DefaultCollation) at
> ../common/charinfo.cpp:455
> #16 0x7facf1afa34f in CollationDB::getCollationName (this=0x7facf1f25440
> , co=CharInfo::DefaultCollation,
> retUnknownAsBlank=0) at ../common/charinfo.cpp:466
> #17 0x7facf1afa649 in CharInfo::getCollationName
> (co=CharInfo::DefaultCollation, retUnknownAsBlank=0) at
> ../common/charinfo.cpp:584
> #18 0x7facf1b7ecad in NAType::convertTypeToText (text=0x7fad11e8e6c0 "INT
> UNSIGNED", fs_datatype=0, length=60, precision=0, scale=0,
> datetimestart=REC_DATE_UNKNOWN, datetimeend=REC_DATE_UNKNOWN,
> datetimefractprec=0, intervalleadingprec=0, upshift=0, caseinsensitive=0,
> charSet=CharInfo::ISO88591, collation=CharInfo::DefaultCollation,
> displaydatatype=0x0, displayCaseSpecific=0) at ../common/NAType.cpp:693
> #19 0x7face933bc7a in Generator::createColDescs (tableName=0x7facea48af18
> "EXPLAIN__", columnInfo=0x7face97d4c00 ,
> numCols=14, offset=@0x7fad11e8e8c4: 66, space=0x0) at
> ../generator/Generator.cpp:1444
> #20 0x7face93784ff in ExplainFunc::createVirtualTableDesc
> (this=0x7fad11e8ec90) at ../generator/GenExplain.cpp:2233
> #21 0x7face944b484 in RelRoot::codeGen (this=0x7facd61a7a50,
> generator=0x7fad11e90c60) at ../generator/GenRelMisc.cpp:1226
> #22 0x7face9339d6b in Generator::genCode (this=0x7fad11e90c60,
> source=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where
> CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME =
> 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access",
> expr_node=0x7facd61a7a50) at ../generator/Generator.cpp:577
> #23 0x7facebe6763b in CmpMain::compile (this=0x7fad11e92d60,
> input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where
> CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME =
> 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", charset=15,
> queryExpr=@0x7fad11e92bb8: 0x7facd61a7a50, gen_code=0x7facd9cda718,
> gen_code_len=0x7facd9cda710, heap=0x7facdfab40b8, phase=CmpMain::END,
> fragmentDir=0x7fad11e92df0, op=3004,
[jira] [Created] (TRAFODION-2783) jdbc_test_cdh fails at times with type 2 JDBC driver dumping core
Selvaganesan Govindarajan created TRAFODION-2783: Summary: jdbc_test_cdh fails at times with type 2 JDBC driver dumping core Key: TRAFODION-2783 URL: https://issues.apache.org/jira/browse/TRAFODION-2783 Project: Apache Trafodion Issue Type: Bug Components: sql-general Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating The stack trace of the core is Thread 1 (Thread 0x7fad11e95700 (LWP 38697)): #0 0x7fad110a95f7 in raise () from /lib64/libc.so.6 #1 0x7fad110aace8 in abort () from /lib64/libc.so.6 2 0x7fad0fecb9d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #3 0x7fad0fec9946 in ?? () from /lib64/libstdc++.so.6 #4 0x7fad0fec9973 in std::terminate() () from /lib64/libstdc++.so.6 #5 0x7fad0feca4df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 #6 0x7fad109ebc76 in outputStream::print_cr(char const*, ...) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #7 0x7fad10b7ca07 in VMError::report(outputStream*) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #8 0x7fad10b7e69f in VMError::report_and_die() () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #9 0x7fad109e85c7 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #10 0x7fad109dc848 in signalHandler(int, siginfo_t*, void*) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #11 #12 0x7facf1afbfad in NACollection::constEntry (this=0x7facf1f25440 , ix=0) at ../common/Collections.h:410 #13 0x7facf1afb786 in NAList::operator[] (this=0x7facf1f25440 , i=0) at ../common/Collections.cpp:924 #14 0x7facf1afb014 in NAList::at (this=0x7facf1f25440 , i=0) at ../common/Collections.h:2058 #15 0x7facf1afa2be in CollationDB::getCollationInfo (this=0x7facf1f25440 , co=CharInfo::DefaultCollation) at ../common/charinfo.cpp:455 #16 0x7facf1afa34f in CollationDB::getCollationName (this=0x7facf1f25440 , co=CharInfo::DefaultCollation, retUnknownAsBlank=0) at ../common/charinfo.cpp:466 #17 0x7facf1afa649 in CharInfo::getCollationName (co=CharInfo::DefaultCollation, retUnknownAsBlank=0) at ../common/charinfo.cpp:584 #18 0x7facf1b7ecad in NAType::convertTypeToText (text=0x7fad11e8e6c0 "INT UNSIGNED", fs_datatype=0, length=60, precision=0, scale=0, datetimestart=REC_DATE_UNKNOWN, datetimeend=REC_DATE_UNKNOWN, datetimefractprec=0, intervalleadingprec=0, upshift=0, caseinsensitive=0, charSet=CharInfo::ISO88591, collation=CharInfo::DefaultCollation, displaydatatype=0x0, displayCaseSpecific=0) at ../common/NAType.cpp:693 #19 0x7face933bc7a in Generator::createColDescs (tableName=0x7facea48af18 "EXPLAIN__", columnInfo=0x7face97d4c00 , numCols=14, offset=@0x7fad11e8e8c4: 66, space=0x0) at ../generator/Generator.cpp:1444 #20 0x7face93784ff in ExplainFunc::createVirtualTableDesc (this=0x7fad11e8ec90) at ../generator/GenExplain.cpp:2233 #21 0x7face944b484 in RelRoot::codeGen (this=0x7facd61a7a50, generator=0x7fad11e90c60) at ../generator/GenRelMisc.cpp:1226 #22 0x7face9339d6b in Generator::genCode (this=0x7fad11e90c60, source=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", expr_node=0x7facd61a7a50) at ../generator/Generator.cpp:577 #23 0x7facebe6763b in CmpMain::compile (this=0x7fad11e92d60, input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", charset=15, queryExpr=@0x7fad11e92bb8: 0x7facd61a7a50, gen_code=0x7facd9cda718, gen_code_len=0x7facd9cda710, heap=0x7facdfab40b8, phase=CmpMain::END, fragmentDir=0x7fad11e92df0, op=3004, useQueryCache=CmpMain::NORMAL, cacheable=0x7fad11e92ba4, begTime=0x7fad11e92bc0, shouldLog=0) at ../sqlcomp/CmpMain.cpp:2453 #24 0x7facebe65170 in CmpMain::sqlcomp (this=0x7fad11e92d60, input_str=0x7facd9cebd08 "select object_name from \"_MD_\".OBJECTS where CATALOG_NAME = 'TRAFODION' and SCHEMA_NAME = '_MD_'\n and OBJECT_NAME = 'OBJECTS' and OBJECT_TYPE = 'BT' for browse access", charset=15, queryExpr=@0x7fad11e92bb8: 0x7facd61a7a50, gen_code=0x7facd9cda718, gen_code_len=0x7facd9cda710, heap=0x7facdfab40b8, phase=CmpMain::END, fragmentDir=0x7fad11e92df0, op=3004, useQueryCache=CmpMain::NORMAL, cacheable=0x7fad11e92ba4, begTime=0x7fad11e92bc0, shouldLog=0) at ../sqlcomp/CmpMain.cpp:1730 #25
[jira] [Resolved] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
[ https://issues.apache.org/jira/browse/TRAFODION-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2780. -- Resolution: Fixed Fix Version/s: 2.3-incubating https://github.com/apache/incubator-trafodion/pull/1273 > Mxosrvr dumps core when connection idle timer expires at times > -- > > Key: TRAFODION-2780 > URL: https://issues.apache.org/jira/browse/TRAFODION-2780 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > Mxosrvr dumps core at times when the connection idle timer expires with the > following stack trace. This core is accompanied by mxssmp core. > Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): > #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 > #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 > #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 > "../executor/ex_root.cpp", l=l@entry=3055, > m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", > c=c@entry=0x0) at ../export/NAAbort.cpp:277 > #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, > waitStartTime=waitStartTime@entry=212373626065770962) at > ../executor/ex_root.cpp:3055 > #4 0x7f95e44515c4 in CliStatement::releaseTransaction > (this=this@entry=0x7f95e8b33d70, > allWorkRequests=allWorkRequests@entry=1, > alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, > statementRemainsOpen=statementRemainsOpen@entry=0) at > ../cli/Statement.cpp:965 > #5 0x7f95e4451990 in CliStatement::releaseTcbs > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 > #6 0x7f95e4451b33 in CliStatement::dealloc > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 > #7 0x7f95e445269a in CliStatement::close > (this=this@entry=0x7f95e8b33d70, diagsArea=..., > inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 > #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, > SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag > __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) > (cliGlobals=, > tasks=1800, statement_id=, > input_descriptor=input_descriptor@entry=0x0, > output_descriptor=output_descriptor@entry=0x0, > num_input_ptr_pairs=num_input_ptr_pairs@entry=0, > num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, > input_ptr_pairs=input_ptr_pairs@entry=0x0, > output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 > #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, > statement_id=) > at ../cli/Cli.cpp:3518 > #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at > ../cli/CliExtern.cpp:1432 > #11 0x7f95e7379757 in SRVR::releaseCachedObject > (internalStmt=internalStmt@entry=0, > mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at > srvrcommon.cpp:764 > #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag= out>) at SrvrConnect.cpp:4648 > #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, > request=, > countRead=, receive_info=) at > ../Common/FileSystemSrvr.cpp:601 > #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, > cc=@0x7ffc86677a84: 6, countRead=16, > call_id=) at ../Common/Listener.cpp:272 > #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, > TcpProcessName=, > port=, TransportTrace=) at > Interface/linux/Listener_srvr_ps.cpp:508 > #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber= out>, > TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 > #17 main (argc=39, argv=0x7ffc8667a948, envp=) at > SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
[ https://issues.apache.org/jira/browse/TRAFODION-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213070#comment-16213070 ] Selvaganesan Govindarajan commented on TRAFODION-2780: -- Thanks Rao. Currently, BreakDialogue is getting called in listener thread, this is the SQL thread as well But, reading the BreakDialogue code it doesn’t seem to switch to this thread ( also it can’t because this listener thread is stuck either in doing SQL work or waiting for the message from the client) The other solution could be to do select with timeout equivalent to connect idle timer. If the select times out, it is possible to breakDiagloue or whatever the method connectIdleTimer was called. Let me make a change and try it out. Selva > Mxosrvr dumps core when connection idle timer expires at times > -- > > Key: TRAFODION-2780 > URL: https://issues.apache.org/jira/browse/TRAFODION-2780 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Mxosrvr dumps core at times when the connection idle timer expires with the > following stack trace. This core is accompanied by mxssmp core. > Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): > #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 > #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 > #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 > "../executor/ex_root.cpp", l=l@entry=3055, > m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", > c=c@entry=0x0) at ../export/NAAbort.cpp:277 > #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, > waitStartTime=waitStartTime@entry=212373626065770962) at > ../executor/ex_root.cpp:3055 > #4 0x7f95e44515c4 in CliStatement::releaseTransaction > (this=this@entry=0x7f95e8b33d70, > allWorkRequests=allWorkRequests@entry=1, > alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, > statementRemainsOpen=statementRemainsOpen@entry=0) at > ../cli/Statement.cpp:965 > #5 0x7f95e4451990 in CliStatement::releaseTcbs > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 > #6 0x7f95e4451b33 in CliStatement::dealloc > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 > #7 0x7f95e445269a in CliStatement::close > (this=this@entry=0x7f95e8b33d70, diagsArea=..., > inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 > #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, > SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag > __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) > (cliGlobals=, > tasks=1800, statement_id=, > input_descriptor=input_descriptor@entry=0x0, > output_descriptor=output_descriptor@entry=0x0, > num_input_ptr_pairs=num_input_ptr_pairs@entry=0, > num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, > input_ptr_pairs=input_ptr_pairs@entry=0x0, > output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 > #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, > statement_id=) > at ../cli/Cli.cpp:3518 > #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at > ../cli/CliExtern.cpp:1432 > #11 0x7f95e7379757 in SRVR::releaseCachedObject > (internalStmt=internalStmt@entry=0, > mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at > srvrcommon.cpp:764 > #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag= out>) at SrvrConnect.cpp:4648 > #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, > request=, > countRead=, receive_info=) at > ../Common/FileSystemSrvr.cpp:601 > #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, > cc=@0x7ffc86677a84: 6, countRead=16, > call_id=) at ../Common/Listener.cpp:272 > #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, > TcpProcessName=, > port=, TransportTrace=) at > Interface/linux/Listener_srvr_ps.cpp:508 > #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber= out>, > TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 > #17 main (argc=39, argv=0x7ffc8667a948, envp=) at > SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
[ https://issues.apache.org/jira/browse/TRAFODION-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213069#comment-16213069 ] Selvaganesan Govindarajan commented on TRAFODION-2780: -- Rao suggested the following Wearing developer hat:)... as far as I remember the code, what we can do is to call breakdialog when the timer expires... which gets to the mainly thread which will execute the disconnect that cleans up. As long as code is not changed since I am out of touch:). It’s the same logic of cleanup when client goes away and breakdialog is invoked. Might work? Thanks Rao > Mxosrvr dumps core when connection idle timer expires at times > -- > > Key: TRAFODION-2780 > URL: https://issues.apache.org/jira/browse/TRAFODION-2780 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Mxosrvr dumps core at times when the connection idle timer expires with the > following stack trace. This core is accompanied by mxssmp core. > Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): > #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 > #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 > #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 > "../executor/ex_root.cpp", l=l@entry=3055, > m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", > c=c@entry=0x0) at ../export/NAAbort.cpp:277 > #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, > waitStartTime=waitStartTime@entry=212373626065770962) at > ../executor/ex_root.cpp:3055 > #4 0x7f95e44515c4 in CliStatement::releaseTransaction > (this=this@entry=0x7f95e8b33d70, > allWorkRequests=allWorkRequests@entry=1, > alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, > statementRemainsOpen=statementRemainsOpen@entry=0) at > ../cli/Statement.cpp:965 > #5 0x7f95e4451990 in CliStatement::releaseTcbs > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 > #6 0x7f95e4451b33 in CliStatement::dealloc > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 > #7 0x7f95e445269a in CliStatement::close > (this=this@entry=0x7f95e8b33d70, diagsArea=..., > inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 > #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, > SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag > __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) > (cliGlobals=, > tasks=1800, statement_id=, > input_descriptor=input_descriptor@entry=0x0, > output_descriptor=output_descriptor@entry=0x0, > num_input_ptr_pairs=num_input_ptr_pairs@entry=0, > num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, > input_ptr_pairs=input_ptr_pairs@entry=0x0, > output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 > #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, > statement_id=) > at ../cli/Cli.cpp:3518 > #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at > ../cli/CliExtern.cpp:1432 > #11 0x7f95e7379757 in SRVR::releaseCachedObject > (internalStmt=internalStmt@entry=0, > mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at > srvrcommon.cpp:764 > #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag= out>) at SrvrConnect.cpp:4648 > #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, > request=, > countRead=, receive_info=) at > ../Common/FileSystemSrvr.cpp:601 > #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, > cc=@0x7ffc86677a84: 6, countRead=16, > call_id=) at ../Common/Listener.cpp:272 > #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, > TcpProcessName=, > port=, TransportTrace=) at > Interface/linux/Listener_srvr_ps.cpp:508 > #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber= out>, > TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 > #17 main (argc=39, argv=0x7ffc8667a948, envp=) at > SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
[ https://issues.apache.org/jira/browse/TRAFODION-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213068#comment-16213068 ] Selvaganesan Govindarajan commented on TRAFODION-2780: -- One possible solution is to send a message to DCS master/DCS server to send the disconnect request. This should avoid the mxosrvr server. > Mxosrvr dumps core when connection idle timer expires at times > -- > > Key: TRAFODION-2780 > URL: https://issues.apache.org/jira/browse/TRAFODION-2780 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Mxosrvr dumps core at times when the connection idle timer expires with the > following stack trace. This core is accompanied by mxssmp core. > Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): > #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 > #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 > #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 > "../executor/ex_root.cpp", l=l@entry=3055, > m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", > c=c@entry=0x0) at ../export/NAAbort.cpp:277 > #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, > waitStartTime=waitStartTime@entry=212373626065770962) at > ../executor/ex_root.cpp:3055 > #4 0x7f95e44515c4 in CliStatement::releaseTransaction > (this=this@entry=0x7f95e8b33d70, > allWorkRequests=allWorkRequests@entry=1, > alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, > statementRemainsOpen=statementRemainsOpen@entry=0) at > ../cli/Statement.cpp:965 > #5 0x7f95e4451990 in CliStatement::releaseTcbs > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 > #6 0x7f95e4451b33 in CliStatement::dealloc > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 > #7 0x7f95e445269a in CliStatement::close > (this=this@entry=0x7f95e8b33d70, diagsArea=..., > inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 > #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, > SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag > __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) > (cliGlobals=, > tasks=1800, statement_id=, > input_descriptor=input_descriptor@entry=0x0, > output_descriptor=output_descriptor@entry=0x0, > num_input_ptr_pairs=num_input_ptr_pairs@entry=0, > num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, > input_ptr_pairs=input_ptr_pairs@entry=0x0, > output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 > #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, > statement_id=) > at ../cli/Cli.cpp:3518 > #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at > ../cli/CliExtern.cpp:1432 > #11 0x7f95e7379757 in SRVR::releaseCachedObject > (internalStmt=internalStmt@entry=0, > mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at > srvrcommon.cpp:764 > #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag= out>) at SrvrConnect.cpp:4648 > #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, > request=, > countRead=, receive_info=) at > ../Common/FileSystemSrvr.cpp:601 > #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, > cc=@0x7ffc86677a84: 6, countRead=16, > call_id=) at ../Common/Listener.cpp:272 > #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, > TcpProcessName=, > port=, TransportTrace=) at > Interface/linux/Listener_srvr_ps.cpp:508 > #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber= out>, > TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 > #17 main (argc=39, argv=0x7ffc8667a948, envp=) at > SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
[ https://issues.apache.org/jira/browse/TRAFODION-2780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16213061#comment-16213061 ] Selvaganesan Govindarajan commented on TRAFODION-2780: -- Analysis of the core from the customer shows the following: gdb) p cli_globals->defaultContext_ ->hbaseClientJNI_ ->tid_ $3 = 47059 But the connection idle timer kicks in thread 47052 and attempts to close the opened statements in the connection as part of connection end processing. The statement that is being closed is a select statement which wasn't closed by the application. , Closing the statement from a different thread is in violation of SQL concepts because of thread specific opens. This need to be fixed in mxosrvr so that the connection close processing as part of ConnectionIdleTimer can happen in the SQL thread 47059. Disconnect from the client would have happened in 47059. > Mxosrvr dumps core when connection idle timer expires at times > -- > > Key: TRAFODION-2780 > URL: https://issues.apache.org/jira/browse/TRAFODION-2780 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Mxosrvr dumps core at times when the connection idle timer expires with the > following stack trace. This core is accompanied by mxssmp core. > Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): > #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 > #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 > #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 > "../executor/ex_root.cpp", l=l@entry=3055, > m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", > c=c@entry=0x0) at ../export/NAAbort.cpp:277 > #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, > waitStartTime=waitStartTime@entry=212373626065770962) at > ../executor/ex_root.cpp:3055 > #4 0x7f95e44515c4 in CliStatement::releaseTransaction > (this=this@entry=0x7f95e8b33d70, > allWorkRequests=allWorkRequests@entry=1, > alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, > statementRemainsOpen=statementRemainsOpen@entry=0) at > ../cli/Statement.cpp:965 > #5 0x7f95e4451990 in CliStatement::releaseTcbs > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 > #6 0x7f95e4451b33 in CliStatement::dealloc > (this=this@entry=0x7f95e8b33d70, > closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 > #7 0x7f95e445269a in CliStatement::close > (this=this@entry=0x7f95e8b33d70, diagsArea=..., > inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 > #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, > SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag > __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) > (cliGlobals=, > tasks=1800, statement_id=, > input_descriptor=input_descriptor@entry=0x0, > output_descriptor=output_descriptor@entry=0x0, > num_input_ptr_pairs=num_input_ptr_pairs@entry=0, > num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, > input_ptr_pairs=input_ptr_pairs@entry=0x0, > output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 > #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, > statement_id=) > at ../cli/Cli.cpp:3518 > #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at > ../cli/CliExtern.cpp:1432 > #11 0x7f95e7379757 in SRVR::releaseCachedObject > (internalStmt=internalStmt@entry=0, > mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at > srvrcommon.cpp:764 > #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag= out>) at SrvrConnect.cpp:4648 > #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, > request=, > countRead=, receive_info=) at > ../Common/FileSystemSrvr.cpp:601 > #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, > cc=@0x7ffc86677a84: 6, countRead=16, > call_id=) at ../Common/Listener.cpp:272 > #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, > TcpProcessName=, > port=, TransportTrace=) at > Interface/linux/Listener_srvr_ps.cpp:508 > #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber= out>, > TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 > #17 main (argc=39, argv=0x7ffc8667a948, envp=) at > SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2780) Mxosrvr dumps core when connection idle timer expires at times
Selvaganesan Govindarajan created TRAFODION-2780: Summary: Mxosrvr dumps core when connection idle timer expires at times Key: TRAFODION-2780 URL: https://issues.apache.org/jira/browse/TRAFODION-2780 Project: Apache Trafodion Issue Type: Bug Components: connectivity-mxosrvr Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Mxosrvr dumps core at times when the connection idle timer expires with the following stack trace. This core is accompanied by mxssmp core. Thread 1 (Thread 0x7f95e8cd4a00 (LWP 47052)): #0 0x7f95e4b135f7 in raise () from /lib64/libc.so.6 #1 0x7f95e4b14e28 in abort () from /lib64/libc.so.6 #2 0x7f95e1158bef in assert_botch_abend (f=f@entry=0x7f95e2ee50d7 "../executor/ex_root.cpp", l=l@entry=3055, m=m@entry=0x7f95e2ee5338 "Timeout waiting for control broker.", c=c@entry=0x0) at ../export/NAAbort.cpp:277 #3 0x7f95e2da911b in ex_root_tcb::cbMessageWait (this=0x7f95af1d4d78, waitStartTime=waitStartTime@entry=212373626065770962) at ../executor/ex_root.cpp:3055 #4 0x7f95e44515c4 in CliStatement::releaseTransaction (this=this@entry=0x7f95e8b33d70, allWorkRequests=allWorkRequests@entry=1, alwaysSendReleaseMsg=alwaysSendReleaseMsg@entry=0, statementRemainsOpen=statementRemainsOpen@entry=0) at ../cli/Statement.cpp:965 #5 0x7f95e4451990 in CliStatement::releaseTcbs (this=this@entry=0x7f95e8b33d70, closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4306 #6 0x7f95e4451b33 in CliStatement::dealloc (this=this@entry=0x7f95e8b33d70, closeAllOpens=closeAllOpens@entry=0) at ../cli/Statement.cpp:4394 #7 0x7f95e445269a in CliStatement::close (this=this@entry=0x7f95e8b33d70, diagsArea=..., inRollback=inRollback@entry=0) at ../cli/Statement.cpp:1140 #8 0x7f95e4411704 in SQLCLI_PerformTasks(CliGlobals *, ULng32, SQLSTMT_ID *, SQLDESC_ID *, SQLDESC_ID *, Lng32, Lng32, typedef __va_list_tag __va_list_tag *, SQLCLI_PTR_PAIRS *, SQLCLI_PTR_PAIRS *) (cliGlobals=, tasks=1800, statement_id=, input_descriptor=input_descriptor@entry=0x0, output_descriptor=output_descriptor@entry=0x0, num_input_ptr_pairs=num_input_ptr_pairs@entry=0, num_output_ptr_pairs=num_output_ptr_pairs@entry=0, ap=ap@entry=0x0, input_ptr_pairs=input_ptr_pairs@entry=0x0, output_ptr_pairs=output_ptr_pairs@entry=0x0) at ../cli/Cli.cpp:3465 #9 0x7f95e4411d04 in SQLCLI_CloseStmt (cliGlobals=, statement_id=) at ../cli/Cli.cpp:3518 #10 0x7f95e445c83f in SQL_EXEC_CloseStmt (statement_id=0x10eed778) at ../cli/CliExtern.cpp:1432 #11 0x7f95e7379757 in SRVR::releaseCachedObject (internalStmt=internalStmt@entry=0, mxsrvr_substate=mxsrvr_substate@entry=NDCS_CONN_IDLE) at srvrcommon.cpp:764 #12 0x004bdf45 in SRVR::connIdleTimerExpired (timer_tag=) at SrvrConnect.cpp:4648 #13 0x00490362 in BUILD_TIMER_MSG_CALL (call_id_=, request=, countRead=, receive_info=) at ../Common/FileSystemSrvr.cpp:601 #14 0x00492075 in CNSKListener::CheckReceiveMessage (this=0x263bea0, cc=@0x7ffc86677a84: 6, countRead=16, call_id=) at ../Common/Listener.cpp:272 #15 0x0049b14e in CNSKListenerSrvr::runProgram (this=0x263bea0, TcpProcessName=, port=, TransportTrace=) at Interface/linux/Listener_srvr_ps.cpp:508 #16 0x00483cc6 in runCEE (TransportTrace=0, portNumber=, TcpProcessName=0x7ffc866789d0 "$ZTC0") at SrvrMain.cpp:167 #17 main (argc=39, argv=0x7ffc8667a948, envp=) at SrvrMain.cpp:864 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2768) Make Trafodion code base to compile in RH7
[ https://issues.apache.org/jira/browse/TRAFODION-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2768. -- Resolution: Fixed > Make Trafodion code base to compile in RH7 > -- > > Key: TRAFODION-2768 > URL: https://issues.apache.org/jira/browse/TRAFODION-2768 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Currently Trafodion can be built in RH6 version. Trafodion can't be built in > RH7 and it fails with many compilation warnings. The compilation warnings in > SQL part of the trafodion code are turned into errors. > Fix the trafodion code to compile without warnings in RH7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2688) Need a way to find queries that are stuck in compilation via RMS
[ https://issues.apache.org/jira/browse/TRAFODION-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2688. -- Resolution: Fixed > Need a way to find queries that are stuck in compilation via RMS > > > Key: TRAFODION-2688 > URL: https://issues.apache.org/jira/browse/TRAFODION-2688 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > When a query is stuck in compilation, there is no way to find it easily. The > mxosrvr remains in connected state forever. Connection idle timer doesn't > kick in. The query timeout can't cancel this query because the query hasn't > start executing. There is a need to find the process id of the > mxosrvr(master) process that is stuck in compilation via RMS. Then the > mxosrvr process can be killed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2727) Memory leak in the compiler part of the code in Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2727. -- Resolution: Fixed > Memory leak in the compiler part of the code in Trafodion > - > > Key: TRAFODION-2727 > URL: https://issues.apache.org/jira/browse/TRAFODION-2727 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The master executor process like mxosrvr which has the compiler embedded > within it, grows in virtual memory overtime. Trafodion i uses its own memory > management via heap to manage its memory needs during execution. The > embedded compiler is also expected to use this infrastructure to manage its > memory needs. However, while executor is being build using this > infrastructure from ground up, it was an after thought in case of compiler. > Some objects in trafodion mixup both its own heap and system heap while > allocating leading to memory leak. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2754) Get statistics cores sqlci or mxosrvr at str_sprintf()
[ https://issues.apache.org/jira/browse/TRAFODION-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2754. -- Resolution: Fixed > Get statistics cores sqlci or mxosrvr at str_sprintf() > --- > > Key: TRAFODION-2754 > URL: https://issues.apache.org/jira/browse/TRAFODION-2754 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > As shown below, select * from table(statistics()) cores sqlci (when using > sqlci) or mxosrvr (when using trafci) with a core. The core indicates that > ExMasterStats::getVariableStatsInfo() has crashed at str_sprintf(). > $ sqlci > >>obey mytest.sql; > >>set schema trafodion.g_tpch2x; > --- SQL operation complete. > >> > >>prepare xx from select > +>cast( (100.00 * sum(case > +>when p_type like 'PROMO%' > +>then l_extendedprice * (1 - l_discount) > +>else 0 > +>end) / sum(l_extendedprice * (1 - l_discount)) > +>) as numeric(18,3)) as promo_revenue > +>from > +>lineitem, > +>part > +>where > +>l_partkey = p_partkey > +>and l_shipdate >= date '1996-01-01' > +>and l_shipdate < date '1996-01-01' + interval '1' month; > --- SQL command prepared. > >> > >>explain options 'f' xx; > LC RC OP OPERATOR OPT DESCRIPTION CARD > - > 8 . 9 root 1.00E+000 > 7 . 8 sort_partial_aggr_ro 1.00E+000 > 6 . 7 esp_exchange 1:7(hash2) 1.00E+000 > 5 . 6 sort_partial_aggr_le 1.00E+000 > 4 2 5 hybrid_hash_join 1.53E+005 > 3 . 4 esp_exchange 7(hash2):8(hash2) 4.00E+005 > . . 3 trafodion_scan PART 4.00E+005 > 1 . 2 esp_exchange 7(hash2):4(hash2) 1.53E+005 > . . 1 trafodion_scan LINEITEM 1.53E+005 > --- SQL operation complete. > >>execute xx; > PROMO_REVENUE > - >16.448 > --- 1 row(s) selected. > >>get statistics for qid current; > Qid MXID11505572123716596998574970206U308T15000_19_XX > Compile Start Time 2017/09/08 12:41:45.751039 > Compile End Time 2017/09/08 12:41:54.318958 > Compile Elapsed Time 0:00:08.567919 > Execute Start Time 2017/09/08 12:41:54.371318 > Execute End Time 2017/09/08 12:41:57.024031 > Execute Elapsed Time 0:00:02.652713 > State CLOSE > Rows Affected 0 > SQL Error Code 100 > Stats Error Code 0 > Query Type SQL_SELECT_NON_UNIQUE > Sub Query Type SQL_STMT_NA > Estimated Accessed Rows 0 > Estimated Used Rows 0 > Parent Qid NONE > Parent Query System NONE > Child Qid NONE > Number of SQL Processes 9 > Number of Cpus 1 > Transaction Id -1 > Source String select cast( (100.00 * sum(case when p_type like 'PROMO%' then > l_extendedprice * (1 - l_discount) else 0 end) / sum(l_extendedprice * (1 - > l_discount)) ) as numeric(18,3)) as promo_revenue from lineitem, part where > l_partkey = p_partkey and l_shipdate >= > SQL Source Length 329 > Rows Returned 1 > First Row Returned Time 2017/09/08 12:41:57.022748 > Last Error before AQR 0 > Number of AQR retries 0 > Delay before AQR 0 > No. of times reclaimed 0 > Cancel Time -1 > Last Suspend Time -1 > Query hash 7788260225241981733 > SLA Name defaultSLA > Profile Name defaultProfile > No. of times executed 1 > Min. Execute Time 2.652713 secs > Max. Execute Time 2.652713 secs > Avg. Execute Time 2.652713 secs > Stats Collection Type OPERATOR_STATS > SQL Process Busy Time 14,018,562 > UDR Process Busy Time 0 > SQL Space Allocated 48,416 KB > SQL Space Used 47,741 KB > SQL Heap Allocated 809 KB > SQL Heap Used 322 KB > SQL Heap WM 22,621 KB > Processes Created 8 > Process Create Time 230,970 > Request Message Count 2,803 > Request Message Bytes 767,576 > Reply Message Count 2,694 > Reply Message Bytes 31,439,144 > BMO Space Buffer Size 256 > BMO Space Buffer Count 21 > BMO Interim Row Count 154,291 > Scr. Overflow Mode DISK > Scr. File Count 0 > Scr. IO Size 0 > Scr. Read Count 0 > Scr. Write Count 0 > Scr. IO Max Time 0 > Sort TopN -1 >Id DOP Table Name > EstRowsAccess ActRowsAccess EstRowsUsed ActRowsUsed SE_IOs SE_IO_KBytes > SE_IO_SumTime SE_IO_MaxTime > 1 4 TRAF_QATEST:TRAFODION.G_TPCH2X.LINEITEM > 0 154,291 153,879 154,291 161 24,250 1,151,209 326,747 > 6 8 TRAF_QATEST:TRAFODION.G_TPCH2X.PART > 0 400,000 400,000 400,000 402 70,986 1,490,487 320,272 > --- SQL operation complete. > >> > >>-- Execute the following statement with from the output above. > >>-- select * from table(statistics(null, 'QID=')); > >> > >>select * from table(statistics(null, > >>'QID=MXID11505572123716596998574970206U308T15000_19_XX')); > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x7f9af8d67352, pid=50557, tid=140303659776480 > # > # JRE version: Java(TM) SE Runtime
[jira] [Resolved] (TRAFODION-2695) SSMP process ($ZSMxxx) sees too many opens from the master process
[ https://issues.apache.org/jira/browse/TRAFODION-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2695. -- Resolution: Fixed > SSMP process ($ZSMxxx) sees too many opens from the master process > -- > > Key: TRAFODION-2695 > URL: https://issues.apache.org/jira/browse/TRAFODION-2695 > Project: Apache Trafodion > Issue Type: Improvement >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > The master processes like mxosrvr or sqlci opens SSMP process to send query > started message and query finished messages. These messages are sent to > provide the capability to cancel the query. > I had observed the following with mxosrvr and mxssmp interactions: > Mxosrvr opens a connection to mxssmp > - For get statistics command > - Managed via ssmpManager_ in the context. This can have connections > to all the ssmps in the cluster > - To cancel a query > - Managed via cbServer_ in ExCancelTcb. This connection is expected > to go away when the cancel is passed on the mxssmp. > - To Send query started /Query finished message > - Managed via cbServer_ in ContextCli. If the cbServer_ is taken up > already by the query with query started message pending, every statement > being executed would create a connection to ssmp and managed via cbServer_ in > ex_root_tcb of the query > I can see many (4) opens in mxssmp dump from a mxosrvr, but I could account > for only one connection on the mxosrvr core dump. For some other clients, I > have seen upto 6-8 opens. > So, I would like to change into a common connection pool for ssmps. The > common connection pool should be managed at the contextCli. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2716) Query compilation gets stuck at listSnapshots() at times
[ https://issues.apache.org/jira/browse/TRAFODION-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2716. -- Resolution: Fixed > Query compilation gets stuck at listSnapshots() at times > > > Key: TRAFODION-2716 > URL: https://issues.apache.org/jira/browse/TRAFODION-2716 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > As part of the query compilation, Admin.listSnapshots() is invoked to get the > latest snapshot of the table unconditionally. listSnapshots is an expensive > API to be called wen there are hundreds of snapshots. > Admin.listTableSnapshots API available in HBase 2.0 can list the snapshots > for a given table. > To reduce the impact on the compilation when there are many snapshots, call > this API only when cqd TRAF_TABLE_SNAPSHOT_SCAN is set to LATEST or SUFFIX. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2733) Provide an improved memory quota assignment for big memory operators (BMO)
[ https://issues.apache.org/jira/browse/TRAFODION-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2733. -- Resolution: Fixed > Provide an improved memory quota assignment for big memory operators (BMO) > -- > > Key: TRAFODION-2733 > URL: https://issues.apache.org/jira/browse/TRAFODION-2733 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp, sql-exe >Affects Versions: 2.3-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The big memory operators in Trafodion are HashJoin, HashGroupBy and Sort. > Trafodion deploys multiple executor server processes (ESPs) to execute a > query via its data flow architecture. Each ESPs can have an instance of this > BMO operator. Currently, each instance of this operator can potentially have > memory quota of 800 MB assigned to do its BMO operation. However, the memory > allocation is usually limited by the memory pressure when this BMO attempts > to allocate memory within the assigned quota. The assignment doesn't depend > upon the estimation of memory needed by this operation. > Improvement needed in BMO memory assignment are: > 1. Limit the memory quota assignment for these BMO operations per node > 2. Memory quota assigned taking into consideration estimated memory needed > at every operator. > 3. Ensure that the BMO gets the minimum memory needed at least to function > smoothly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2738) Rowset buffer size during insert/upsert should be limited
[ https://issues.apache.org/jira/browse/TRAFODION-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2738. -- Resolution: Fixed > Rowset buffer size during insert/upsert should be limited > - > > Key: TRAFODION-2738 > URL: https://issues.apache.org/jira/browse/TRAFODION-2738 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Selvaganesan Govindarajan > > Currently, the rowset size for upsert and insert can be given in a such way > that it would be allocate unlimited buffer size to move the data from client > to Trafodion SQL engine. This can cause memory corruption and unexpected > behavior. Hence, we need a way to limit the number of rows in the rowset. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2698) Ensure RMS can be disabled properly
[ https://issues.apache.org/jira/browse/TRAFODION-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2698. -- Resolution: Fixed > Ensure RMS can be disabled properly > --- > > Key: TRAFODION-2698 > URL: https://issues.apache.org/jira/browse/TRAFODION-2698 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > By default, RMS gets started. If you stop RMS, the shared segment stay around > and hence all the process would continue to assume RMS is up. The proper way > to disable RMS is > export SQ_START_RMS=0 > Then do sqstart > > This would be the proper way to disable RMS in future. > We encounter cores of SQL processes and improper message with the above > scenario. Disabling RMS in the above way ensures that the shared segment is > never used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2696) control query cancel qid fails with error 8031 sometimes
[ https://issues.apache.org/jira/browse/TRAFODION-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2696. -- Resolution: Fixed > control query cancel qid fails with error 8031 sometimes > > > Key: TRAFODION-2696 > URL: https://issues.apache.org/jira/browse/TRAFODION-2696 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > At times even the long running query fails with the following error message > *** ERROR[8031] Server declined cancel request for query ID > MXID1125653212367983150736206U300_106___SQLCI_DML_LAST__. > The query is not registered with the cancel broker. > This error can happen if the ssmp process is restarted after the query start > executing. When the ssmp is restarted, the posted query started message is > lost and hence the query can't be cancelled. However, we can minimize this > failure by avoiding ssmp restarts within the engine whereever possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2631) Disk IO counter is not populated for hdfs/hive IOs
[ https://issues.apache.org/jira/browse/TRAFODION-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2631. -- Resolution: Fixed > Disk IO counter is not populated for hdfs/hive IOs > -- > > Key: TRAFODION-2631 > URL: https://issues.apache.org/jira/browse/TRAFODION-2631 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.2-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > >>select [last 0] * from hive.hive.store_orc ; > .. > --- 0 row(s) selected. > >>fc get > >>get statistics for qid current ; > .. > Qid > MXID1117354212363181358222206U300_157___SQLCI_DML_LAST__ > Compile Start Time 2017/06/02 16:36:58.273995 > Compile End Time 2017/06/02 16:37:00.100361 > Compile Elapsed Time 0:00:01.826366 > Execute Start Time 2017/06/02 16:37:00.100932 > Execute End Time 2017/06/02 16:37:00.538304 > Execute Elapsed Time 0:00:00.437372 > StateDEALLOCATED > Rows Affected0 > SQL Error Code 100 > Stats Error Code 0 > Query Type SQL_SELECT_NON_UNIQUE > Sub Query Type SQL_STMT_NA > Estimated Accessed Rows 0 > Estimated Used Rows 0 > Parent Qid NONE > Parent Query System NONE > Child QidNONE > Number of SQL Processes 1 > Number of Cpus 1 > Transaction Id -1 > Source Stringselect [last 0] * from hive.hive.store_orc ; > SQL Source Length44 > Rows Returned0 > First Row Returned Time -1 > Last Error before AQR0 > Number of AQR retries0 > Delay before AQR 0 > No. of times reclaimed 0 > Cancel Time -1 > Last Suspend Time-1 > Query hash 5095926260958264825 > Stats Collection TypeOPERATOR_STATS > SQL Process Busy Time373,044 > UDR Process Busy Time0 > SQL Space Allocated 9,301 KB > SQL Space Used 9,294 KB > SQL Heap Allocated 10,341KB > SQL Heap Used10,337KB > SQL Heap WM 10,337KB > Processes Created0 > Process Create Time 0 > Request Message Count0 > Request Message Bytes0 > Reply Message Count 0 > Reply Message Bytes 0 > BMO Space Buffer Size0 > BMO Space Buffer Count 0 > BMO Interim Row Count0 > Scr. Overflow Mode UNKNOWN > Scr. File Count 0 > Scr. IO Size 0 > Scr. Read Count 0 > Scr. Write Count 0 > Scr. IO Max Time 0 > Sort TopN-1 >Id DOP Table Name > EstRowsAccess ActRowsAccessEstRowsUsed ActRowsUsed > SE_IOsSE_IO_KBytes SE_IO_SumTime SE_IO_MaxTime > 1 1 HIVE.STORE_ORC > 100 12100 12 >0 4 16,816 16,816 > --- SQL operation complete. > >> > SE_IOs is 0 in the above output -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2681) Repeated execution of prepared SQL select statement causes memory leak
[ https://issues.apache.org/jira/browse/TRAFODION-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2681. -- Resolution: Fixed > Repeated execution of prepared SQL select statement causes memory leak > -- > > Key: TRAFODION-2681 > URL: https://issues.apache.org/jira/browse/TRAFODION-2681 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2768) Make Trafodion code base to compile in RH7
Selvaganesan Govindarajan created TRAFODION-2768: Summary: Make Trafodion code base to compile in RH7 Key: TRAFODION-2768 URL: https://issues.apache.org/jira/browse/TRAFODION-2768 Project: Apache Trafodion Issue Type: Improvement Components: sql-general Reporter: Selvaganesan Govindarajan Currently Trafodion can be built in RH6 version. Trafodion can't be built in RH7 and it fails with many compilation warnings. The compilation warnings in SQL part of the trafodion code are turned into errors. Fix the trafodion code to compile without warnings in RH7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TRAFODION-2768) Make Trafodion code base to compile in RH7
[ https://issues.apache.org/jira/browse/TRAFODION-2768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2768: Assignee: Selvaganesan Govindarajan > Make Trafodion code base to compile in RH7 > -- > > Key: TRAFODION-2768 > URL: https://issues.apache.org/jira/browse/TRAFODION-2768 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Currently Trafodion can be built in RH6 version. Trafodion can't be built in > RH7 and it fails with many compilation warnings. The compilation warnings in > SQL part of the trafodion code are turned into errors. > Fix the trafodion code to compile without warnings in RH7 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2754) Get statistics cores sqlci or mxosrvr at str_sprintf()
Selvaganesan Govindarajan created TRAFODION-2754:
Summary: Get statistics cores sqlci or mxosrvr at str_sprintf()
Key: TRAFODION-2754
URL: https://issues.apache.org/jira/browse/TRAFODION-2754
Project: Apache Trafodion
Issue Type: Bug
Components: sql-exe
Reporter: Selvaganesan Govindarajan
Assignee: Selvaganesan Govindarajan
As shown below, select * from table(statistics()) cores sqlci (when using
sqlci) or mxosrvr (when using trafci) with a core. The core indicates that
ExMasterStats::getVariableStatsInfo() has crashed at str_sprintf().
$ sqlci
>>obey mytest.sql;
>>set schema trafodion.g_tpch2x;
--- SQL operation complete.
>>
>>prepare xx from select
+>cast( (100.00 * sum(case
+>when p_type like 'PROMO%'
+>then l_extendedprice * (1 - l_discount)
+>else 0
+>end) / sum(l_extendedprice * (1 - l_discount))
+>) as numeric(18,3)) as promo_revenue
+>from
+>lineitem,
+>part
+>where
+>l_partkey = p_partkey
+>and l_shipdate >= date '1996-01-01'
+>and l_shipdate < date '1996-01-01' + interval '1' month;
--- SQL command prepared.
>>
>>explain options 'f' xx;
LC RC OP OPERATOR OPT DESCRIPTION CARD
-
8 . 9 root 1.00E+000
7 . 8 sort_partial_aggr_ro 1.00E+000
6 . 7 esp_exchange 1:7(hash2) 1.00E+000
5 . 6 sort_partial_aggr_le 1.00E+000
4 2 5 hybrid_hash_join 1.53E+005
3 . 4 esp_exchange 7(hash2):8(hash2) 4.00E+005
. . 3 trafodion_scan PART 4.00E+005
1 . 2 esp_exchange 7(hash2):4(hash2) 1.53E+005
. . 1 trafodion_scan LINEITEM 1.53E+005
--- SQL operation complete.
>>execute xx;
PROMO_REVENUE
-
16.448
--- 1 row(s) selected.
>>get statistics for qid current;
Qid MXID11505572123716596998574970206U308T15000_19_XX
Compile Start Time 2017/09/08 12:41:45.751039
Compile End Time 2017/09/08 12:41:54.318958
Compile Elapsed Time 0:00:08.567919
Execute Start Time 2017/09/08 12:41:54.371318
Execute End Time 2017/09/08 12:41:57.024031
Execute Elapsed Time 0:00:02.652713
State CLOSE
Rows Affected 0
SQL Error Code 100
Stats Error Code 0
Query Type SQL_SELECT_NON_UNIQUE
Sub Query Type SQL_STMT_NA
Estimated Accessed Rows 0
Estimated Used Rows 0
Parent Qid NONE
Parent Query System NONE
Child Qid NONE
Number of SQL Processes 9
Number of Cpus 1
Transaction Id -1
Source String select cast( (100.00 * sum(case when p_type like 'PROMO%' then
l_extendedprice * (1 - l_discount) else 0 end) / sum(l_extendedprice * (1 -
l_discount)) ) as numeric(18,3)) as promo_revenue from lineitem, part where
l_partkey = p_partkey and l_shipdate >=
SQL Source Length 329
Rows Returned 1
First Row Returned Time 2017/09/08 12:41:57.022748
Last Error before AQR 0
Number of AQR retries 0
Delay before AQR 0
No. of times reclaimed 0
Cancel Time -1
Last Suspend Time -1
Query hash 7788260225241981733
SLA Name defaultSLA
Profile Name defaultProfile
No. of times executed 1
Min. Execute Time 2.652713 secs
Max. Execute Time 2.652713 secs
Avg. Execute Time 2.652713 secs
Stats Collection Type OPERATOR_STATS
SQL Process Busy Time 14,018,562
UDR Process Busy Time 0
SQL Space Allocated 48,416 KB
SQL Space Used 47,741 KB
SQL Heap Allocated 809 KB
SQL Heap Used 322 KB
SQL Heap WM 22,621 KB
Processes Created 8
Process Create Time 230,970
Request Message Count 2,803
Request Message Bytes 767,576
Reply Message Count 2,694
Reply Message Bytes 31,439,144
BMO Space Buffer Size 256
BMO Space Buffer Count 21
BMO Interim Row Count 154,291
Scr. Overflow Mode DISK
Scr. File Count 0
Scr. IO Size 0
Scr. Read Count 0
Scr. Write Count 0
Scr. IO Max Time 0
Sort TopN -1
Id DOP Table Name
EstRowsAccess ActRowsAccess EstRowsUsed ActRowsUsed SE_IOs SE_IO_KBytes
SE_IO_SumTime SE_IO_MaxTime
1 4 TRAF_QATEST:TRAFODION.G_TPCH2X.LINEITEM
0 154,291 153,879 154,291 161 24,250 1,151,209 326,747
6 8 TRAF_QATEST:TRAFODION.G_TPCH2X.PART
0 400,000 400,000 400,000 402 70,986 1,490,487 320,272
--- SQL operation complete.
>>
>>-- Execute the following statement with from the output above.
>>-- select * from table(statistics(null, 'QID='));
>>
>>select * from table(statistics(null,
>>'QID=MXID11505572123716596998574970206U308T15000_19_XX'));
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7f9af8d67352, pid=50557, tid=140303659776480
#
# JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [libcommon.so+0x10a352] str_len(char const*)+0x2
#
# Core dump written. Default location: /home/trafodion/bugs/core or core.50557
#
# An error report file with more information is saved as:
# /home/trafodion/bugs/hs_err_pid50557.log
#
# If you would like to submit a bug report,
[jira] [Created] (TRAFODION-2739) RMS semaphore handling need to log the error for easy resolution of the issue
Selvaganesan Govindarajan created TRAFODION-2739: Summary: RMS semaphore handling need to log the error for easy resolution of the issue Key: TRAFODION-2739 URL: https://issues.apache.org/jira/browse/TRAFODION-2739 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating Currently, RMS doesn't log the error when semaphore can't be locked or released, though it dumps the core. Because the error code is optimized out it is becoming difficult to get the error code from the core. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2738) Rowset buffer size during insert/upsert should be limited
Selvaganesan Govindarajan created TRAFODION-2738: Summary: Rowset buffer size during insert/upsert should be limited Key: TRAFODION-2738 URL: https://issues.apache.org/jira/browse/TRAFODION-2738 Project: Apache Trafodion Issue Type: Bug Reporter: Selvaganesan Govindarajan Currently, the rowset size for upsert and insert can be given in a such way that it would be allocate unlimited buffer size to move the data from client to Trafodion SQL engine. This can cause memory corruption and unexpected behavior. Hence, we need a way to limit the number of rows in the rowset. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2737) Native hbase table access via Trafodion improvements/issues
Selvaganesan Govindarajan created TRAFODION-2737: Summary: Native hbase table access via Trafodion improvements/issues Key: TRAFODION-2737 URL: https://issues.apache.org/jira/browse/TRAFODION-2737 Project: Apache Trafodion Issue Type: Improvement Components: sql-cmp, sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating Native hbase table access via Trafodion needs the following: a) Get a row given a hbase row Id doesn't work at times b) Need a way to specify hbase row id length and hbase row length c) Need a way to support List (Rowset Get in Trafodion terms) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TRAFODION-2733) Provide an improved memory quota assignment for big memory operators (BMO)
[ https://issues.apache.org/jira/browse/TRAFODION-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2733: - Summary: Provide an improved memory quota assignment for big memory operators (BMO) (was: Provide a improved memory quota assignment for big memory operators (BMO)) > Provide an improved memory quota assignment for big memory operators (BMO) > -- > > Key: TRAFODION-2733 > URL: https://issues.apache.org/jira/browse/TRAFODION-2733 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp, sql-exe >Affects Versions: 2.3-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.3-incubating > > > The big memory operators in Trafodion are HashJoin, HashGroupBy and Sort. > Trafodion deploys multiple executor server processes (ESPs) to execute a > query via its data flow architecture. Each ESPs can have an instance of this > BMO operator. Currently, each instance of this operator can potentially have > memory quota of 800 MB assigned to do its BMO operation. However, the memory > allocation is usually limited by the memory pressure when this BMO attempts > to allocate memory within the assigned quota. The assignment doesn't depend > upon the estimation of memory needed by this operation. > Improvement needed in BMO memory assignment are: > 1. Limit the memory quota assignment for these BMO operations per node > 2. Memory quota assigned taking into consideration estimated memory needed > at every operator. > 3. Ensure that the BMO gets the minimum memory needed at least to function > smoothly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2733) Provide a improved memory quota assignment for big memory operators (BMO)
Selvaganesan Govindarajan created TRAFODION-2733: Summary: Provide a improved memory quota assignment for big memory operators (BMO) Key: TRAFODION-2733 URL: https://issues.apache.org/jira/browse/TRAFODION-2733 Project: Apache Trafodion Issue Type: Improvement Components: sql-cmp, sql-exe Affects Versions: 2.3-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.3-incubating The big memory operators in Trafodion are HashJoin, HashGroupBy and Sort. Trafodion deploys multiple executor server processes (ESPs) to execute a query via its data flow architecture. Each ESPs can have an instance of this BMO operator. Currently, each instance of this operator can potentially have memory quota of 800 MB assigned to do its BMO operation. However, the memory allocation is usually limited by the memory pressure when this BMO attempts to allocate memory within the assigned quota. The assignment doesn't depend upon the estimation of memory needed by this operation. Improvement needed in BMO memory assignment are: 1. Limit the memory quota assignment for these BMO operations per node 2. Memory quota assigned taking into consideration estimated memory needed at every operator. 3. Ensure that the BMO gets the minimum memory needed at least to function smoothly -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2711) Error 8026 is shown at times when the query is cancelled.
Selvaganesan Govindarajan created TRAFODION-2711: Summary: Error 8026 is shown at times when the query is cancelled. Key: TRAFODION-2711 URL: https://issues.apache.org/jira/browse/TRAFODION-2711 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 2.2-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Priority: Critical When control query cancel qid is issued even when the query id can be found via get statistics for qid and the query is in cancellable state, the error below is shown at times. *** ERROR[8026] Server declined cancel request. The query ID of the targeted query was not found. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2698) Ensure RMS can be disabled properly
Selvaganesan Govindarajan created TRAFODION-2698: Summary: Ensure RMS can be disabled properly Key: TRAFODION-2698 URL: https://issues.apache.org/jira/browse/TRAFODION-2698 Project: Apache Trafodion Issue Type: Improvement Components: sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.2-incubating By default, RMS gets started. If you stop RMS, the shared segment stay around and hence all the process would continue to assume RMS is up. The proper way to disable RMS is export SQ_START_RMS=0 Then do sqstart This would be the proper way to disable RMS in future. We encounter cores of SQL processes and improper message with the above scenario. Disabling RMS in the above way ensures that the shared segment is never used. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (TRAFODION-2696) control query cancel qid fails with error 8031 sometimes
[ https://issues.apache.org/jira/browse/TRAFODION-2696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2696: - Summary: control query cancel qid fails with error 8031 sometimes (was: At time control query cancel qid fails with error 8031) > control query cancel qid fails with error 8031 sometimes > > > Key: TRAFODION-2696 > URL: https://issues.apache.org/jira/browse/TRAFODION-2696 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > At times even the long running query fails with the following error message > *** ERROR[8031] Server declined cancel request for query ID > MXID1125653212367983150736206U300_106___SQLCI_DML_LAST__. > The query is not registered with the cancel broker. > This error can happen if the ssmp process is restarted after the query start > executing. When the ssmp is restarted, the posted query started message is > lost and hence the query can't be cancelled. However, we can minimize this > failure by avoiding ssmp restarts within the engine whereever possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2696) At time control query cancel qid fails with error 8031
Selvaganesan Govindarajan created TRAFODION-2696: Summary: At time control query cancel qid fails with error 8031 Key: TRAFODION-2696 URL: https://issues.apache.org/jira/browse/TRAFODION-2696 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.2-incubating At times even the long running query fails with the following error message *** ERROR[8031] Server declined cancel request for query ID MXID1125653212367983150736206U300_106___SQLCI_DML_LAST__. The query is not registered with the cancel broker. This error can happen if the ssmp process is restarted after the query start executing. When the ssmp is restarted, the posted query started message is lost and hence the query can't be cancelled. However, we can minimize this failure by avoiding ssmp restarts within the engine whereever possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TRAFODION-2695) SSMP process ($ZSMxxx) sees too many opens from the master process
[ https://issues.apache.org/jira/browse/TRAFODION-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2695: Assignee: Selvaganesan Govindarajan > SSMP process ($ZSMxxx) sees too many opens from the master process > -- > > Key: TRAFODION-2695 > URL: https://issues.apache.org/jira/browse/TRAFODION-2695 > Project: Apache Trafodion > Issue Type: Improvement >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > The master processes like mxosrvr or sqlci opens SSMP process to send query > started message and query finished messages. These messages are sent to > provide the capability to cancel the query. > I had observed the following with mxosrvr and mxssmp interactions: > Mxosrvr opens a connection to mxssmp > - For get statistics command > - Managed via ssmpManager_ in the context. This can have connections > to all the ssmps in the cluster > - To cancel a query > - Managed via cbServer_ in ExCancelTcb. This connection is expected > to go away when the cancel is passed on the mxssmp. > - To Send query started /Query finished message > - Managed via cbServer_ in ContextCli. If the cbServer_ is taken up > already by the query with query started message pending, every statement > being executed would create a connection to ssmp and managed via cbServer_ in > ex_root_tcb of the query > I can see many (4) opens in mxssmp dump from a mxosrvr, but I could account > for only one connection on the mxosrvr core dump. For some other clients, I > have seen upto 6-8 opens. > So, I would like to change into a common connection pool for ssmps. The > common connection pool should be managed at the contextCli. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2695) SSMP process ($ZSMxxx) sees too many opens from the master process
Selvaganesan Govindarajan created TRAFODION-2695: Summary: SSMP process ($ZSMxxx) sees too many opens from the master process Key: TRAFODION-2695 URL: https://issues.apache.org/jira/browse/TRAFODION-2695 Project: Apache Trafodion Issue Type: Improvement Reporter: Selvaganesan Govindarajan The master processes like mxosrvr or sqlci opens SSMP process to send query started message and query finished messages. These messages are sent to provide the capability to cancel the query. I had observed the following with mxosrvr and mxssmp interactions: Mxosrvr opens a connection to mxssmp - For get statistics command - Managed via ssmpManager_ in the context. This can have connections to all the ssmps in the cluster - To cancel a query - Managed via cbServer_ in ExCancelTcb. This connection is expected to go away when the cancel is passed on the mxssmp. - To Send query started /Query finished message - Managed via cbServer_ in ContextCli. If the cbServer_ is taken up already by the query with query started message pending, every statement being executed would create a connection to ssmp and managed via cbServer_ in ex_root_tcb of the query I can see many (4) opens in mxssmp dump from a mxosrvr, but I could account for only one connection on the mxosrvr core dump. For some other clients, I have seen upto 6-8 opens. So, I would like to change into a common connection pool for ssmps. The common connection pool should be managed at the contextCli. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TRAFODION-2688) Need a way to find queries that are stuck in compilation via RMS
[ https://issues.apache.org/jira/browse/TRAFODION-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2688: Assignee: Selvaganesan Govindarajan > Need a way to find queries that are stuck in compilation via RMS > > > Key: TRAFODION-2688 > URL: https://issues.apache.org/jira/browse/TRAFODION-2688 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > When a query is stuck in compilation, there is no way to find it easily. The > mxosrvr remains in connected state forever. Connection idle timer doesn't > kick in. The query timeout can't cancel this query because the query hasn't > start executing. There is a need to find the process id of the > mxosrvr(master) process that is stuck in compilation via RMS. Then the > mxosrvr process can be killed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (TRAFODION-2688) Need a way to find queries that are stuck in compilation via RMS
[ https://issues.apache.org/jira/browse/TRAFODION-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-2688 started by Selvaganesan Govindarajan. > Need a way to find queries that are stuck in compilation via RMS > > > Key: TRAFODION-2688 > URL: https://issues.apache.org/jira/browse/TRAFODION-2688 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > When a query is stuck in compilation, there is no way to find it easily. The > mxosrvr remains in connected state forever. Connection idle timer doesn't > kick in. The query timeout can't cancel this query because the query hasn't > start executing. There is a need to find the process id of the > mxosrvr(master) process that is stuck in compilation via RMS. Then the > mxosrvr process can be killed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2688) Need a way to find queries that are stuck in compilation via RMS
Selvaganesan Govindarajan created TRAFODION-2688: Summary: Need a way to find queries that are stuck in compilation via RMS Key: TRAFODION-2688 URL: https://issues.apache.org/jira/browse/TRAFODION-2688 Project: Apache Trafodion Issue Type: Improvement Components: sql-exe Reporter: Selvaganesan Govindarajan When a query is stuck in compilation, there is no way to find it easily. The mxosrvr remains in connected state forever. Connection idle timer doesn't kick in. The query timeout can't cancel this query because the query hasn't start executing. There is a need to find the process id of the mxosrvr(master) process that is stuck in compilation via RMS. Then the mxosrvr process can be killed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2681) Repeated execution of prepared SQL select statement causes memory leak
Selvaganesan Govindarajan created TRAFODION-2681: Summary: Repeated execution of prepared SQL select statement causes memory leak Key: TRAFODION-2681 URL: https://issues.apache.org/jira/browse/TRAFODION-2681 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 2.0-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.2-incubating -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2654) Change the location of trafodion-site.xml from $TRAF_HOME/etc to config
[ https://issues.apache.org/jira/browse/TRAFODION-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2654. -- Resolution: Fixed Fix Version/s: 2.2-incubating https://github.com/apache/incubator-trafodion/pull/1143 > Change the location of trafodion-site.xml from $TRAF_HOME/etc to config > --- > > Key: TRAFODION-2654 > URL: https://issues.apache.org/jira/browse/TRAFODION-2654 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.2-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > Conf directory needs to be used from any configuration. conf directory is > used for log4j and log4cxx configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (TRAFODION-2653) Sort operator loops at times
[ https://issues.apache.org/jira/browse/TRAFODION-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2653. -- Resolution: Fixed Fix Version/s: 2.2-incubating For details see https://github.com/apache/incubator-trafodion/pull/1143 > Sort operator loops at times > > > Key: TRAFODION-2653 > URL: https://issues.apache.org/jira/browse/TRAFODION-2653 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.2-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > This issue was observed in Esgyn internal testing. When the system is heavily > loaded, the scratch IOs can return EAGAIN that translates to > OPERATION_NOT_COMPLETE in Sort scratch IO handling. This condition is not > being handled correctly. > Scratch IO doesn't use asynchronous IOs though the scratch file is opened in > non-blocking mode. EAGAIN is returned from these IO operations very rarely. > It should be fine to open the scratch file in blocking mode to avoid this > problem -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TRAFODION-2654) Change the location of trafodion-site.xml from $TRAF_HOME/etc to config
[ https://issues.apache.org/jira/browse/TRAFODION-2654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2654: Assignee: Selvaganesan Govindarajan > Change the location of trafodion-site.xml from $TRAF_HOME/etc to config > --- > > Key: TRAFODION-2654 > URL: https://issues.apache.org/jira/browse/TRAFODION-2654 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.2-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Conf directory needs to be used from any configuration. conf directory is > used for log4j and log4cxx configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (TRAFODION-2653) Sort operator loops at times
[ https://issues.apache.org/jira/browse/TRAFODION-2653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2653: Assignee: Selvaganesan Govindarajan > Sort operator loops at times > > > Key: TRAFODION-2653 > URL: https://issues.apache.org/jira/browse/TRAFODION-2653 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.2-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > This issue was observed in Esgyn internal testing. When the system is heavily > loaded, the scratch IOs can return EAGAIN that translates to > OPERATION_NOT_COMPLETE in Sort scratch IO handling. This condition is not > being handled correctly. > Scratch IO doesn't use asynchronous IOs though the scratch file is opened in > non-blocking mode. EAGAIN is returned from these IO operations very rarely. > It should be fine to open the scratch file in blocking mode to avoid this > problem -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2654) Change the location of trafodion-site.xml from $TRAF_HOME/etc to config
Selvaganesan Govindarajan created TRAFODION-2654: Summary: Change the location of trafodion-site.xml from $TRAF_HOME/etc to config Key: TRAFODION-2654 URL: https://issues.apache.org/jira/browse/TRAFODION-2654 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 2.2-incubating Reporter: Selvaganesan Govindarajan Conf directory needs to be used from any configuration. conf directory is used for log4j and log4cxx configuration. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2653) Sort operator loops at times
Selvaganesan Govindarajan created TRAFODION-2653: Summary: Sort operator loops at times Key: TRAFODION-2653 URL: https://issues.apache.org/jira/browse/TRAFODION-2653 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 2.2-incubating Reporter: Selvaganesan Govindarajan This issue was observed in Esgyn internal testing. When the system is heavily loaded, the scratch IOs can return EAGAIN that translates to OPERATION_NOT_COMPLETE in Sort scratch IO handling. This condition is not being handled correctly. Scratch IO doesn't use asynchronous IOs though the scratch file is opened in non-blocking mode. EAGAIN is returned from these IO operations very rarely. It should be fine to open the scratch file in blocking mode to avoid this problem -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (TRAFODION-2631) Disk IO counter is not populated for hdfs/hive IOs
Selvaganesan Govindarajan created TRAFODION-2631: Summary: Disk IO counter is not populated for hdfs/hive IOs Key: TRAFODION-2631 URL: https://issues.apache.org/jira/browse/TRAFODION-2631 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: 2.2-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.2-incubating >>select [last 0] * from hive.hive.store_orc ; .. --- 0 row(s) selected. >>fc get >>get statistics for qid current ; .. Qid MXID1117354212363181358222206U300_157___SQLCI_DML_LAST__ Compile Start Time 2017/06/02 16:36:58.273995 Compile End Time 2017/06/02 16:37:00.100361 Compile Elapsed Time 0:00:01.826366 Execute Start Time 2017/06/02 16:37:00.100932 Execute End Time 2017/06/02 16:37:00.538304 Execute Elapsed Time 0:00:00.437372 StateDEALLOCATED Rows Affected0 SQL Error Code 100 Stats Error Code 0 Query Type SQL_SELECT_NON_UNIQUE Sub Query Type SQL_STMT_NA Estimated Accessed Rows 0 Estimated Used Rows 0 Parent Qid NONE Parent Query System NONE Child QidNONE Number of SQL Processes 1 Number of Cpus 1 Transaction Id -1 Source Stringselect [last 0] * from hive.hive.store_orc ; SQL Source Length44 Rows Returned0 First Row Returned Time -1 Last Error before AQR0 Number of AQR retries0 Delay before AQR 0 No. of times reclaimed 0 Cancel Time -1 Last Suspend Time-1 Query hash 5095926260958264825 Stats Collection TypeOPERATOR_STATS SQL Process Busy Time373,044 UDR Process Busy Time0 SQL Space Allocated 9,301 KB SQL Space Used 9,294 KB SQL Heap Allocated 10,341KB SQL Heap Used10,337KB SQL Heap WM 10,337KB Processes Created0 Process Create Time 0 Request Message Count0 Request Message Bytes0 Reply Message Count 0 Reply Message Bytes 0 BMO Space Buffer Size0 BMO Space Buffer Count 0 BMO Interim Row Count0 Scr. Overflow Mode UNKNOWN Scr. File Count 0 Scr. IO Size 0 Scr. Read Count 0 Scr. Write Count 0 Scr. IO Max Time 0 Sort TopN-1 Id DOP Table Name EstRowsAccess ActRowsAccessEstRowsUsed ActRowsUsed SE_IOsSE_IO_KBytes SE_IO_SumTime SE_IO_MaxTime 1 1 HIVE.STORE_ORC 100 12100 12 0 4 16,816 16,816 --- SQL operation complete. >> SE_IOs is 0 in the above output -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-1906) Dop is reported incorrectly in RMS operator stats
[ https://issues.apache.org/jira/browse/TRAFODION-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-1906. > Dop is reported incorrectly in RMS operator stats > - > > Key: TRAFODION-1906 > URL: https://issues.apache.org/jira/browse/TRAFODION-1906 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Sandhya Sundaresan >Assignee: Selvaganesan Govindarajan > > The Degree of parallelism is icorrectly reported in some operators. THis > needs to be tested and fixed so it's consistent in all operators. > The work may take quite some effort . -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-1906) Dop is reported incorrectly in RMS operator stats
[ https://issues.apache.org/jira/browse/TRAFODION-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-1906. -- Resolution: Fixed This issue is resolved as part of TRAFODION-2420 RMS enhancements PRs > Dop is reported incorrectly in RMS operator stats > - > > Key: TRAFODION-1906 > URL: https://issues.apache.org/jira/browse/TRAFODION-1906 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Sandhya Sundaresan >Assignee: Selvaganesan Govindarajan > > The Degree of parallelism is icorrectly reported in some operators. THis > needs to be tested and fixed so it's consistent in all operators. > The work may take quite some effort . -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2074) Create index should avoid populating the index within a transaction
[ https://issues.apache.org/jira/browse/TRAFODION-2074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2074. > Create index should avoid populating the index within a transaction > --- > > Key: TRAFODION-2074 > URL: https://issues.apache.org/jira/browse/TRAFODION-2074 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > Populating the index is done via load command. Load command doesn't need > transaction. Transactions in Trafodion have 2hr expiry period. If the load > takes more than 2 hours to populate the index the create index will always > fail. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2134) Change the overflow_mode to 'DISK' by default
[ https://issues.apache.org/jira/browse/TRAFODION-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2134. > Change the overflow_mode to 'DISK' by default > - > > Key: TRAFODION-2134 > URL: https://issues.apache.org/jira/browse/TRAFODION-2134 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > Original Estimate: 24h > Remaining Estimate: 24h > > In queries involving Block Memory Operators (BMOs), Trafodion can overflow > the data from the data flow into scratch files. These scratch files are > currently being memory mapped which puts pressure on the memory usage on the > node when there is large amount of overflow. The default needs to be changed > to DISK -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2262) Mxosrvr or Java core with the stack trace pointing to log4Cxx functions
[ https://issues.apache.org/jira/browse/TRAFODION-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2262. > Mxosrvr or Java core with the stack trace pointing to log4Cxx functions > --- > > Key: TRAFODION-2262 > URL: https://issues.apache.org/jira/browse/TRAFODION-2262 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Reporter: Dennis Markt >Assignee: Selvaganesan Govindarajan > > There appears to be two types of cores generated but I can't seem to find the > other back trace you mentioned Selva. Please add the bt or more information > to make this Case more useful. > Thanks, > Dennis -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2306) Trafodion customization using its own configuration file.
[ https://issues.apache.org/jira/browse/TRAFODION-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2306. > Trafodion customization using its own configuration file. > - > > Key: TRAFODION-2306 > URL: https://issues.apache.org/jira/browse/TRAFODION-2306 > Project: Apache Trafodion > Issue Type: Improvement > Components: dtm, sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > From: Selva Govindarajan [mailto:selva.govindara...@esgyn.com] > Sent: Friday, October 21, 2016 6:15 PM > To: d...@trafodion.incubator.apache.org > Subject: [DISCUSS] Introducing Trafodion customization using its own > configuration file. > > Currently Trafodion uses the standard client side Hbase configuration > file hbase-site.xml deployed by the distros. It is found that there are > variations in this configuration file between distros. At times, the distro > manager decides that a given property is not a client property and it is not > added to the deployed hbase client configuration file. In addition, there are > certain properties like hbase.coprocessor.region.classes need to be > configured for Trafodion tables for the transaction management. Hence, I am > planning to introduce a configuration file traf-site.xml specific to > Trafodion similar to hbase configuration file hbase-site.xml. This > configuration file extends the properties inherited from the standard > hbase-site.xml. > > By default, the traf-site.xml comes with the following properties > > > > > > > > > hbase.hregion.impl > > org.apache.hadoop.hbase.regionserver.transactional.TransactionalRegion > > > hbase.coprocessor.region.classes > > > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionObserver, > > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint, >org.apache.hadoop.hbase.coprocessor.AggregateImplementation > > > > hbase.client.scanner.timeout.period > 360 > > > > This property file will be installed if it doesn't exist at > $MY_SQROOT/etc directory when sqgen is done. Any client side property can be > added to this file and the client connections from Trafodion client processes > will inherit them. > > The hbase.coprocessor.region.classes are added as Table co-processor to > the table descriptor when a Trafodion table is created. Trafodion installer > will not be adding to these properties to hbase configuration file soon. > > Please feel free to provide your valuable suggestions/comments. > > Thanks > Selva > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2303) Limit the heap size of hbase processes for co-operative developer environment
[ https://issues.apache.org/jira/browse/TRAFODION-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2303. > Limit the heap size of hbase processes for co-operative developer environment > - > > Key: TRAFODION-2303 > URL: https://issues.apache.org/jira/browse/TRAFODION-2303 > Project: Apache Trafodion > Issue Type: Improvement > Components: dev-environment >Affects Versions: 2.1-incubating > Environment: Developer environment >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Minor > Fix For: 2.1-incubating > > > In the developer environment, the HBase processes are started without setting > max heap size. Then, HBase java processes uses 1/4 of the physical memory as > the max heap size. This results in memory pressure in a cooperative developer > environment shared by many developers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2314) MXOSRVR sometimes exit abnormally with NAMutex assert
[ https://issues.apache.org/jira/browse/TRAFODION-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2314. > MXOSRVR sometimes exit abnormally with NAMutex assert > - > > Key: TRAFODION-2314 > URL: https://issues.apache.org/jira/browse/TRAFODION-2314 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Arvind Narain >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > Following errors were noticed during a jdbc_test regression run. These tests > usually pass on reruns. > 2016-10-26 10:54:18 Running TestBigColumnSize > 2016-10-26 10:54:18 --- > 2016-10-26 10:54:29 32KColSizeWithUTF8 : Pass > 2016-10-26 10:54:44 200KColSizeWithUTF8 : Pass > 2016-10-26 10:54:44 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time > elapsed: 25.573 sec - in TestBigColumnSize > 2016-10-26 10:54:44 Running TestTrx > 2016-10-26 10:54:44 org.trafodion.jdbc.t4.TrafT4Exception: Server aborted > abnormally or Connection timed out > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.TrafT4Messages.createSQLException(TrafT4Messages.java:284) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.InputOutput.doIO(InputOutput.java:376) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.T4Connection.getReadBuffer(T4Connection.java:157) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.T4Connection.InitializeDialogue(T4Connection.java:220) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.InterfaceConnection.initDiag(InterfaceConnection.java:534) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.InterfaceConnection.secureLogin(InterfaceConnection.java:710) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.InterfaceConnection.connect(InterfaceConnection.java:904) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.InterfaceConnection.(InterfaceConnection.java:176) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.TrafT4Connection.makeConnection(TrafT4Connection.java:1611) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.TrafT4Connection.(TrafT4Connection.java:1564) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.TrafT4DataSource.getConnection(TrafT4DataSource.java:132) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.TrafT4DataSource.getConnection(TrafT4DataSource.java:176) > 2016-10-26 10:54:44 at > org.trafodion.jdbc.t4.T4Driver.connect(T4Driver.java:186) > 2016-10-26 10:54:44 at > java.sql.DriverManager.getConnection(DriverManager.java:571) > 2016-10-26 10:54:44 at > java.sql.DriverManager.getConnection(DriverManager.java:215) > 2016-10-26 10:54:44 at Utils.getUserConnection(Utils.java:125) > 2016-10-26 10:54:44 at TestTrx.JDBCTrx1(TestTrx.java:53) > Corresponding errors in mon.snmp log file: > 2016-10-26 10:54:44,446, INFO, MON, Node Number: 0,, PIN: 41028 , Process > Name: $MONITOR,,, TID: 41033, Message ID: 101130801, STDERR redirected from > slave-ahw23.$Z0012AF.0.45690: mxosrvr: ../common/NAMemory.cpp:183: > NAMutex::~NAMutex(): Assertion `rc == 0' failed. > Corresponding message from monitor.map file: > BEGIN Wed Oct 26 10:48:59 2016 $Z0012AF (0, 45690:47) P(-1, -1:-1) mxosrvr > .. > BEGIN Wed Oct 26 10:54:32 2016 $Z0018UZ (0, 53724:84) P(0, 45690:47) > /home/jenkins/workspace/jdbc_test-hdp/traf_run/tdm_arkcmp > END Wed Oct 26 10:54:44 2016 $Z0018UZ (0, 53724:84) P(0, 45690:47) > /home/jenkins/workspace/jdbc_test-hdp/traf_run/tdm_arkcmp > END Wed Oct 26 10:54:44 2016 $Z0012AF (0, 45690:47) P(-1, -1:-1) mxosrvr > Corresponding master_exec logs: > 2016-10-26 10:54:29,069, INFO, SQL, Node Number: 0, CPU: 0, PIN: 45690, > Process Name: $Z0012AF,,, A compiler process is launched. > 2016-10-26 10:54:31,914, INFO, DBSECURITY, Node Number: 0, CPU: 0, PIN: 45690 > Authentication request: externalUser QA001, databaseUser QA001, userID > 4, clientName slave-ahw23, clientUserName jenkins, result 0 > (Authentication successful) > 2016-10-26 10:54:35,523, INFO, SQL.COMP, Node Number: 0, CPU: 0, PIN: 53724, > Process Name: $Z0018UZ,,, A compiler process is launched. > 2016-10-26 10:54:36,778, ERROR, SQL, Node Number: 0, CPU: 0, PIN: 45690, > Process Name: $Z0012AF, SQLCODE: 1022, QID: > MXID11456902123442389396735850206U400_119_SQL_CUR_1, *** > ERROR[1022] Schema TRAFODION.T4QA already exists. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-2356) Trafodion process can dump core at times because JNIEnv is not initialized
[ https://issues.apache.org/jira/browse/TRAFODION-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2356. -- Resolution: Fixed > Trafodion process can dump core at times because JNIEnv is not initialized > -- > > Key: TRAFODION-2356 > URL: https://issues.apache.org/jira/browse/TRAFODION-2356 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > JNIEnv needs to be initialized before issuing any JNI call from this thread. > Trafodion doesn't ensure that for all of its java methods called from 'C' > side of the SQL engine. It is possible that Type2 JDBC applications can > fail, if the connection is made in one thread and the actual SQL is executed > from another thread. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2514) Obscure cores seen in Trafodion while running jenkins tests with RH7
[ https://issues.apache.org/jira/browse/TRAFODION-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2514. > Obscure cores seen in Trafodion while running jenkins tests with RH7 > > > Key: TRAFODION-2514 > URL: https://issues.apache.org/jira/browse/TRAFODION-2514 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation, sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.2-incubating > > > Core dump in foundation layer is as follows > #1 0x7fbd387d9ce8 in abort () from /lib64/libc.so.6 > #2 0x7fbd375fa965 in __gnu_cxx::__verbose_terminate_handler() () from > /lib64/libstdc++.so.6 > #3 0x7fbd375f8946 in ?? () from /lib64/libstdc++.so.6 > #4 0x7fbd375f8973 in std::terminate() () from /lib64/libstdc++.so.6 > #5 0x7fbd375f94df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 > #6 0x7fbd382adaec in VMError::report_and_die() () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #7 0x7fbd381175c7 in JVM_handle_linux_signal () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #8 0x7fbd3810b848 in signalHandler(int, siginfo_t*, void*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #9 > #10 0x051245a0 in ?? () > #11 0x7fbd1174888c in SignalHandler(int) () from > /home/jenkins/workspace/core-regress-executor-cdh/traf_run/export/lib64/libtdm_sqlexp.so > #12 > #13 0x7fbd387d85f7 in raise () from /lib64/libc.so.6 > #14 0x7fbd387d9ce8 in abort () from /lib64/libc.so.6 > #15 0x7fbd375fa9d5 in __gnu_cxx::__verbose_terminate_handler() () from > /lib64/libstdc++.so.6 > #16 0x7fbd375f8946 in ?? () from /lib64/libstdc++.so.6 > #17 0x7fbd375f8973 in std::terminate() () from /lib64/libstdc++.so.6 > #18 0x7fbd375f94df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 > #19 0x7fbd3811ac76 in outputStream::print_cr(char const*, ...) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #20 0x7fbd382aba07 in VMError::report(outputStream*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #21 0x7fbd382ad69f in VMError::report_and_die() () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #22 0x7fbd381175c7 in JVM_handle_linux_signal () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #23 0x7fbd3810b848 in signalHandler(int, siginfo_t*, void*) () from > /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so > #24 > #25 0x in ?? () > #26 0x7fbd1244d211 in SB_Ts_Table_Mgr::free_entry > (this=0x7fbd126636a0 , pv_inx=1) at tablemgr.inl:265 > #27 0x7fbd1244ba7c in sb_thread_ctx_key_dtor (pp_ctx=0x4bd5a00) at > threadl.cpp:192 > #28 0x7fbd39195bc2 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 > #29 0x7fbd39195dd3 in start_thread () from /lib64/libpthread.so.0 > #30 0x7fbd38899ced in clone () from /lib64/libc.so.6 > Core dump in SQL layer is as follows > Thread 1 (Thread 0x7fa8421a1a80 (LWP 52446)): > #0 0x7fa83f1e05f7 in raise () from /lib64/libc.so.6 > #1 0x7fa83f1e1e28 in abort () from /lib64/libc.so.6 > #2 0x7fa84107fd99 in os::abort(bool) () from > /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so > #3 0x7fa841220d06 in VMError::report_and_die() () from > /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so > #4 0x7fa841088f47 in JVM_handle_linux_signal () from > /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so > #5 0x7fa84107d1b8 in signalHandler(int, siginfo_t*, void*) () from > /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so > #6 > #7 NAMemory::allocateMemory (this=this@entry=0x7fa700203131, > size=size@entry=332, failureIsFatal=failureIsFatal@entry=1) at > ../common/NAMemory.cpp:1377 > #8 0x7fa84196a2d2 in checkedRealloc (h=0x7fa700203131, newSize=332, > dataSize=282, ptr=0x7fa7c7a2b418) at ../export/FBString.h:304 > #9 smartRealloc (h=0x7fa700203131, newCapacity=332, > currentCapacity=, currentSize=282, p=0x7fa7c7a2b418) at > ../export/FBString.h:348 > #10 reallocate (h=0x7fa700203131, newCapacity=316, currentCapacity= out>, currentSize=266, data=0x7fa7c7a2b420 "scan_type: subset scan of table > TRAFODION.HBASE.CUSTOMER_DEMOGRAPHICS_SALT object_type: Trafodion > cache_size: 1 cache_blocks: OFF probes: 1
[jira] [Closed] (TRAFODION-2469) TM clients like dtmci don't exit cleanly
[ https://issues.apache.org/jira/browse/TRAFODION-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2469. > TM clients like dtmci don't exit cleanly > > > Key: TRAFODION-2469 > URL: https://issues.apache.org/jira/browse/TRAFODION-2469 > Project: Apache Trafodion > Issue Type: Improvement > Components: dtm >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > dtmci opens tm process $TM0, $TM1... but these opens are not closed cleanly > while exiting -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2478) Reduce the number of memory monitoring threads in Trafodion SQL processes
[ https://issues.apache.org/jira/browse/TRAFODION-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2478. > Reduce the number of memory monitoring threads in Trafodion SQL processes > --- > > Key: TRAFODION-2478 > URL: https://issues.apache.org/jira/browse/TRAFODION-2478 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > A memory monitor thread is created in every SQL process to handle the memory > pressure in BMO (Big memory operators). This has following drawbacks: > 1) No consistent view of the memory pressure in the node > 2) Overhead of calculating the memory pressure in every trafodion SQL process. > Proposal is to move this thread to RMS SSCP process. All SQL processes have > access to RMS shared segment. Hence SQL processes can get the view of the > memory pressure readily and easily from the shared segment. > It is also possible to increase the frequency of the memory pressure > calculation to get near real tiime picture of the memory pressure. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2484) Improve SET STATISTICS command to display the information in new format
[ https://issues.apache.org/jira/browse/TRAFODION-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2484. > Improve SET STATISTICS command to display the information in new format > --- > > Key: TRAFODION-2484 > URL: https://issues.apache.org/jira/browse/TRAFODION-2484 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-ci >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > In trafci and sqlci, one can display the execution statistics of the query > after it is completed automatically by issuing the command > set statistics on ; > This command outputs the information in old format. There is a need to output > the statistics information in other new formats for testing purposes and to > understand the execution characteristics of the query -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-2594) Trafodion logs the same message twice in most of its log4j and log4cxx logs
[ https://issues.apache.org/jira/browse/TRAFODION-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2594. -- Resolution: Fixed > Trafodion logs the same message twice in most of its log4j and log4cxx logs > --- > > Key: TRAFODION-2594 > URL: https://issues.apache.org/jira/browse/TRAFODION-2594 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > For an example the SSMP process logs as follows > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2594) Trafodion logs the same message twice in most of its log4j and log4cxx logs
[ https://issues.apache.org/jira/browse/TRAFODION-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2594. > Trafodion logs the same message twice in most of its log4j and log4cxx logs > --- > > Key: TRAFODION-2594 > URL: https://issues.apache.org/jira/browse/TRAFODION-2594 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > For an example the SSMP process logs as follows > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
[ https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2566. > Reduce the virtual memory allocated in Trafodion processes with JDK1.8 > -- > > Key: TRAFODION-2566 > URL: https://issues.apache.org/jira/browse/TRAFODION-2566 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > It is observed that JDK1.8 uses native memory to store class metadata in lieu > of permanent generation of earlier releases. By default, JVM mmaps 1 GB of > virtual address space to the process. Because Trafodion SQL processes are not > generic JVM processes, it is viable to reduce the default JVM mmap for the > class metadata > In JVM1.8 > A simple hello world java program shows the following: > Heap Configuration when java invoked as > java -Xmx512m Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 1073741824 (1024.0MB) >MaxMetaspaceSize = 17592186044415 MB >G1HeapRegionSize = 0 (0.0MB) > Heap Configuration when Java is invoked as > java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m > Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 268435456 (256.0MB) >MaxMetaspaceSize = 268435456 (256.0MB) >G1HeapRegionSize = 0 (0.0MB) > With JDK 1.7 > $JAVA_HOME/bin/java -Xmx512m Sample > Heap Configuration: >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 1310720 (1.25MB) >MaxNewSize = 17592186044415 MB >OldSize = 5439488 (5.1875MB) >NewRatio = 2 >SurvivorRatio= 8 >PermSize = 21757952 (20.75MB) >MaxPermSize = 85983232 (82.0MB) >G1HeapRegionSize = 0 (0.0MB) > Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning > to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
[ https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2566. -- Resolution: Fixed > Reduce the virtual memory allocated in Trafodion processes with JDK1.8 > -- > > Key: TRAFODION-2566 > URL: https://issues.apache.org/jira/browse/TRAFODION-2566 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > It is observed that JDK1.8 uses native memory to store class metadata in lieu > of permanent generation of earlier releases. By default, JVM mmaps 1 GB of > virtual address space to the process. Because Trafodion SQL processes are not > generic JVM processes, it is viable to reduce the default JVM mmap for the > class metadata > In JVM1.8 > A simple hello world java program shows the following: > Heap Configuration when java invoked as > java -Xmx512m Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 1073741824 (1024.0MB) >MaxMetaspaceSize = 17592186044415 MB >G1HeapRegionSize = 0 (0.0MB) > Heap Configuration when Java is invoked as > java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m > Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 268435456 (256.0MB) >MaxMetaspaceSize = 268435456 (256.0MB) >G1HeapRegionSize = 0 (0.0MB) > With JDK 1.7 > $JAVA_HOME/bin/java -Xmx512m Sample > Heap Configuration: >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 1310720 (1.25MB) >MaxNewSize = 17592186044415 MB >OldSize = 5439488 (5.1875MB) >NewRatio = 2 >SurvivorRatio= 8 >PermSize = 21757952 (20.75MB) >MaxPermSize = 85983232 (82.0MB) >G1HeapRegionSize = 0 (0.0MB) > Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning > to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2596) Improve the log4j and log4cxx infrastructure in Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2596. > Improve the log4j and log4cxx infrastructure in Trafodion > - > > Key: TRAFODION-2596 > URL: https://issues.apache.org/jira/browse/TRAFODION-2596 > Project: Apache Trafodion > Issue Type: Improvement >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Currently SQL logs messages in different files identified by the master node > and pid in its name. This creates many log files in $TRAF_HOME/log directory > and makes it unmanageable. > SQL primarily use log4cxx infrastructure for logging error messages and error > events. I believe error messages are written only when the master process > reads the diagnostics area and it is not written when the error originates. > But the error events(SQLMXLogging) might be written by any process. > In addition, all other logs on the java side uses a single log file even when > it is written from multiple processes in our environment. Eg > trafodion.hdfs.log trafodion.dtm.log. Even the C++ logging writes from > multiple processes. The amount of log entries written by SQL from C++ side is > way less than the any other logging within our environment. Definitely, they > pale in comparison with hbase, hive and other Hadoop processes. > So, I think it will be neat solution to log the entries from all SQL > processes into one log file per node -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TRAFODION-2420) RMS enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan closed TRAFODION-2420. > RMS enhancements > > > Key: TRAFODION-2420 > URL: https://issues.apache.org/jira/browse/TRAFODION-2420 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-general >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Improve RMS to provide the following features/capabilities: > 1. Currently RMS can list queries that consumed cpu time between two time > points. However, the calls to storage engine like hbase, hdfs etc are > blocking and these blocked APIs will not allow the Trafodion SQL engine > scheduler to detect the cpu time spent during the time the call was blocked. > Introduce a feature called SE offender (storage engine offender) to list the > queries that are blocked in storage engine more than a certain duration. > 2. Remove counters that are no longer updated or needed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-2420) RMS enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2420. -- Resolution: Fixed > RMS enhancements > > > Key: TRAFODION-2420 > URL: https://issues.apache.org/jira/browse/TRAFODION-2420 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-general >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Improve RMS to provide the following features/capabilities: > 1. Currently RMS can list queries that consumed cpu time between two time > points. However, the calls to storage engine like hbase, hdfs etc are > blocking and these blocked APIs will not allow the Trafodion SQL engine > scheduler to detect the cpu time spent during the time the call was blocked. > Introduce a feature called SE offender (storage engine offender) to list the > queries that are blocked in storage engine more than a certain duration. > 2. Remove counters that are no longer updated or needed -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (TRAFODION-2596) Improve the log4j and log4cxx infrastructure in Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2596: Assignee: Selvaganesan Govindarajan > Improve the log4j and log4cxx infrastructure in Trafodion > - > > Key: TRAFODION-2596 > URL: https://issues.apache.org/jira/browse/TRAFODION-2596 > Project: Apache Trafodion > Issue Type: Improvement >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > Currently SQL logs messages in different files identified by the master node > and pid in its name. This creates many log files in $TRAF_HOME/log directory > and makes it unmanageable. > SQL primarily use log4cxx infrastructure for logging error messages and error > events. I believe error messages are written only when the master process > reads the diagnostics area and it is not written when the error originates. > But the error events(SQLMXLogging) might be written by any process. > In addition, all other logs on the java side uses a single log file even when > it is written from multiple processes in our environment. Eg > trafodion.hdfs.log trafodion.dtm.log. Even the C++ logging writes from > multiple processes. The amount of log entries written by SQL from C++ side is > way less than the any other logging within our environment. Definitely, they > pale in comparison with hbase, hive and other Hadoop processes. > So, I think it will be neat solution to log the entries from all SQL > processes into one log file per node -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TRAFODION-2596) Improve the log4j and log4cxx infrastructure in Trafodion
Selvaganesan Govindarajan created TRAFODION-2596: Summary: Improve the log4j and log4cxx infrastructure in Trafodion Key: TRAFODION-2596 URL: https://issues.apache.org/jira/browse/TRAFODION-2596 Project: Apache Trafodion Issue Type: Improvement Reporter: Selvaganesan Govindarajan Currently SQL logs messages in different files identified by the master node and pid in its name. This creates many log files in $TRAF_HOME/log directory and makes it unmanageable. SQL primarily use log4cxx infrastructure for logging error messages and error events. I believe error messages are written only when the master process reads the diagnostics area and it is not written when the error originates. But the error events(SQLMXLogging) might be written by any process. In addition, all other logs on the java side uses a single log file even when it is written from multiple processes in our environment. Eg trafodion.hdfs.log trafodion.dtm.log. Even the C++ logging writes from multiple processes. The amount of log entries written by SQL from C++ side is way less than the any other logging within our environment. Definitely, they pale in comparison with hbase, hive and other Hadoop processes. So, I think it will be neat solution to log the entries from all SQL processes into one log file per node -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TRAFODION-2594) Trafodion logs the same message twice in most of its log4j and log4cxx logs
Selvaganesan Govindarajan created TRAFODION-2594: Summary: Trafodion logs the same message twice in most of its log4j and log4cxx logs Key: TRAFODION-2594 URL: https://issues.apache.org/jira/browse/TRAFODION-2594 Project: Apache Trafodion Issue Type: Bug Components: sql-general Reporter: Selvaganesan Govindarajan For an example the SSMP process logs as follows 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, Process Name: $ZSM000,,, An ssmp process is launched. 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, Process Name: $ZSM000,,, An ssmp process is launched. 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, Process Name: $ZSM000,,,Early reply to query started message from $Z000MQW:466 to attempt graceful cancel of query MXID11278562123482712133040010206U300_415_S1. Explain Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, Process Name: $ZSM000,,,Early reply to query started message from $Z000MQW:466 to attempt graceful cancel of query MXID11278562123482712133040010206U300_415_S1. Explain Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (TRAFODION-2594) Trafodion logs the same message twice in most of its log4j and log4cxx logs
[ https://issues.apache.org/jira/browse/TRAFODION-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2594: Assignee: Selvaganesan Govindarajan > Trafodion logs the same message twice in most of its log4j and log4cxx logs > --- > > Key: TRAFODION-2594 > URL: https://issues.apache.org/jira/browse/TRAFODION-2594 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-general >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > For an example the SSMP process logs as follows > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-11 01:33:11,994, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,, An ssmp process is launched. > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 > 2016-12-12 02:55:02,141, INFO, SQL.SSMP, Node Number: 0, CPU: 0, PIN: 20666, > Process Name: $ZSM000,,,Early reply to query started message from > $Z000MQW:466 to attempt graceful cancel of query > MXID11278562123482712133040010206U300_415_S1. Explain > Sequence Number: 0 FILE: ../runtimestats/CancelBroker.cpp LINE: 149 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
[ https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948116#comment-15948116 ] Selvaganesan Govindarajan commented on TRAFODION-2566: -- Please provide a better default value for these parameters if you have any other suggestions > Reduce the virtual memory allocated in Trafodion processes with JDK1.8 > -- > > Key: TRAFODION-2566 > URL: https://issues.apache.org/jira/browse/TRAFODION-2566 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > It is observed that JDK1.8 uses native memory to store class metadata in lie > of permanent generation in earlier releases. By default, JVM mmaps 1 GB of > virtual address space to the process. Because Trafodion SQL processes are not > generic JVM processes, it is viable to reduce the default JVM mmap for the > class metadata > In JVM1.8 > A simple hello world java program shows the following: > Heap Configuration when java invoked as > java -Xmx512m Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 1073741824 (1024.0MB) >MaxMetaspaceSize = 17592186044415 MB >G1HeapRegionSize = 0 (0.0MB) > Heap Configuration when Java is invoked as > java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m > Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 268435456 (256.0MB) >MaxMetaspaceSize = 268435456 (256.0MB) >G1HeapRegionSize = 0 (0.0MB) > With JDK 1.7 > $JAVA_HOME/bin/java -Xmx512m Sample > Heap Configuration: >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 1310720 (1.25MB) >MaxNewSize = 17592186044415 MB >OldSize = 5439488 (5.1875MB) >NewRatio = 2 >SurvivorRatio= 8 >PermSize = 21757952 (20.75MB) >MaxPermSize = 85983232 (82.0MB) >G1HeapRegionSize = 0 (0.0MB) > Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning > to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
Selvaganesan Govindarajan created TRAFODION-2566: Summary: Reduce the virtual memory allocated in Trafodion processes with JDK1.8 Key: TRAFODION-2566 URL: https://issues.apache.org/jira/browse/TRAFODION-2566 Project: Apache Trafodion Issue Type: Improvement Components: sql-exe Affects Versions: 2.1-incubating Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan It is observed that JDK1.8 uses native memory to store class metadata in lie of permanent generation in earlier releases. By default, JVM mmaps 1 GB of virtual address space to the process. Because Trafodion SQL processes are not generic JVM processes, it is viable to reduce the default JVM mmap for the class metadata In JVM1.8 A simple hello world java program shows the following: Heap Configuration when java invoked as java -Xmx512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Configuration when Java is invoked as java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 268435456 (256.0MB) MaxMetaspaceSize = 268435456 (256.0MB) G1HeapRegionSize = 0 (0.0MB) With JDK 1.7 $JAVA_HOME/bin/java -Xmx512m Sample Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio= 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) G1HeapRegionSize = 0 (0.0MB) Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
[ https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2566: - Description: It is observed that JDK1.8 uses native memory to store class metadata in lieu of permanent generation of earlier releases. By default, JVM mmaps 1 GB of virtual address space to the process. Because Trafodion SQL processes are not generic JVM processes, it is viable to reduce the default JVM mmap for the class metadata In JVM1.8 A simple hello world java program shows the following: Heap Configuration when java invoked as java -Xmx512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Configuration when Java is invoked as java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 268435456 (256.0MB) MaxMetaspaceSize = 268435456 (256.0MB) G1HeapRegionSize = 0 (0.0MB) With JDK 1.7 $JAVA_HOME/bin/java -Xmx512m Sample Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio= 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) G1HeapRegionSize = 0 (0.0MB) Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. was: It is observed that JDK1.8 uses native memory to store class metadata in lie of permanent generation in earlier releases. By default, JVM mmaps 1 GB of virtual address space to the process. Because Trafodion SQL processes are not generic JVM processes, it is viable to reduce the default JVM mmap for the class metadata In JVM1.8 A simple hello world java program shows the following: Heap Configuration when java invoked as java -Xmx512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Configuration when Java is invoked as java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m Sample MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 178782208 (170.5MB) MaxNewSize = 178782208 (170.5MB) OldSize = 358088704 (341.5MB) NewRatio = 2 SurvivorRatio= 8 MetaspaceSize= 21807104 (20.796875MB) CompressedClassSpaceSize = 268435456 (256.0MB) MaxMetaspaceSize = 268435456 (256.0MB) G1HeapRegionSize = 0 (0.0MB) With JDK 1.7 $JAVA_HOME/bin/java -Xmx512m Sample Heap Configuration: MinHeapFreeRatio = 0 MaxHeapFreeRatio = 100 MaxHeapSize = 536870912 (512.0MB) NewSize = 1310720 (1.25MB) MaxNewSize = 17592186044415 MB OldSize = 5439488 (5.1875MB) NewRatio = 2 SurvivorRatio= 8 PermSize = 21757952 (20.75MB) MaxPermSize = 85983232 (82.0MB) G1HeapRegionSize = 0 (0.0MB) Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. > Reduce the virtual memory allocated in Trafodion processes with JDK1.8 > -- > > Key: TRAFODION-2566 > URL: https://issues.apache.org/jira/browse/TRAFODION-2566 > Project:
[jira] [Work started] (TRAFODION-2566) Reduce the virtual memory allocated in Trafodion processes with JDK1.8
[ https://issues.apache.org/jira/browse/TRAFODION-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on TRAFODION-2566 started by Selvaganesan Govindarajan. > Reduce the virtual memory allocated in Trafodion processes with JDK1.8 > -- > > Key: TRAFODION-2566 > URL: https://issues.apache.org/jira/browse/TRAFODION-2566 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Affects Versions: 2.1-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > It is observed that JDK1.8 uses native memory to store class metadata in lie > of permanent generation in earlier releases. By default, JVM mmaps 1 GB of > virtual address space to the process. Because Trafodion SQL processes are not > generic JVM processes, it is viable to reduce the default JVM mmap for the > class metadata > In JVM1.8 > A simple hello world java program shows the following: > Heap Configuration when java invoked as > java -Xmx512m Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 1073741824 (1024.0MB) >MaxMetaspaceSize = 17592186044415 MB >G1HeapRegionSize = 0 (0.0MB) > Heap Configuration when Java is invoked as > java -XX:MaxMetaspaceSize=256m -XX:CompressedClassSpaceSize=256m -Xmx=512m > Sample >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 178782208 (170.5MB) >MaxNewSize = 178782208 (170.5MB) >OldSize = 358088704 (341.5MB) >NewRatio = 2 >SurvivorRatio= 8 >MetaspaceSize= 21807104 (20.796875MB) >CompressedClassSpaceSize = 268435456 (256.0MB) >MaxMetaspaceSize = 268435456 (256.0MB) >G1HeapRegionSize = 0 (0.0MB) > With JDK 1.7 > $JAVA_HOME/bin/java -Xmx512m Sample > Heap Configuration: >MinHeapFreeRatio = 0 >MaxHeapFreeRatio = 100 >MaxHeapSize = 536870912 (512.0MB) >NewSize = 1310720 (1.25MB) >MaxNewSize = 17592186044415 MB >OldSize = 5439488 (5.1875MB) >NewRatio = 2 >SurvivorRatio= 8 >PermSize = 21757952 (20.75MB) >MaxPermSize = 85983232 (82.0MB) >G1HeapRegionSize = 0 (0.0MB) > Permanent Generation in 1.7 is equivalent to MaxMetaDataSpace. I am planning > to reduce both MaxMetaspaceSize and CompressedClassSpace Size to 128MB. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (TRAFODION-2356) Trafodion process can dump core at times because JNIEnv is not initialized
[ https://issues.apache.org/jira/browse/TRAFODION-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-2356: Assignee: Selvaganesan Govindarajan > Trafodion process can dump core at times because JNIEnv is not initialized > -- > > Key: TRAFODION-2356 > URL: https://issues.apache.org/jira/browse/TRAFODION-2356 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > > JNIEnv needs to be initialized before issuing any JNI call from this thread. > Trafodion doesn't ensure that for all of its java methods called from 'C' > side of the SQL engine. It is possible that Type2 JDBC applications can > fail, if the connection is made in one thread and the actual SQL is executed > from another thread. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TRAFODION-2514) Obscure cores seen in Trafodion while running jenkins tests with RH7
Selvaganesan Govindarajan created TRAFODION-2514: Summary: Obscure cores seen in Trafodion while running jenkins tests with RH7 Key: TRAFODION-2514 URL: https://issues.apache.org/jira/browse/TRAFODION-2514 Project: Apache Trafodion Issue Type: Bug Components: foundation, sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.2-incubating Core dump in foundation layer is as follows #1 0x7fbd387d9ce8 in abort () from /lib64/libc.so.6 #2 0x7fbd375fa965 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #3 0x7fbd375f8946 in ?? () from /lib64/libstdc++.so.6 #4 0x7fbd375f8973 in std::terminate() () from /lib64/libstdc++.so.6 #5 0x7fbd375f94df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 #6 0x7fbd382adaec in VMError::report_and_die() () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #7 0x7fbd381175c7 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #8 0x7fbd3810b848 in signalHandler(int, siginfo_t*, void*) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #9 #10 0x051245a0 in ?? () #11 0x7fbd1174888c in SignalHandler(int) () from /home/jenkins/workspace/core-regress-executor-cdh/traf_run/export/lib64/libtdm_sqlexp.so #12 #13 0x7fbd387d85f7 in raise () from /lib64/libc.so.6 #14 0x7fbd387d9ce8 in abort () from /lib64/libc.so.6 #15 0x7fbd375fa9d5 in __gnu_cxx::__verbose_terminate_handler() () from /lib64/libstdc++.so.6 #16 0x7fbd375f8946 in ?? () from /lib64/libstdc++.so.6 #17 0x7fbd375f8973 in std::terminate() () from /lib64/libstdc++.so.6 #18 0x7fbd375f94df in __cxa_pure_virtual () from /lib64/libstdc++.so.6 #19 0x7fbd3811ac76 in outputStream::print_cr(char const*, ...) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #20 0x7fbd382aba07 in VMError::report(outputStream*) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #21 0x7fbd382ad69f in VMError::report_and_die() () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #22 0x7fbd381175c7 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #23 0x7fbd3810b848 in signalHandler(int, siginfo_t*, void*) () from /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el7_2.x86_64/jre/lib/amd64/server/libjvm.so #24 #25 0x in ?? () #26 0x7fbd1244d211 in SB_Ts_Table_Mgr::free_entry (this=0x7fbd126636a0 , pv_inx=1) at tablemgr.inl:265 #27 0x7fbd1244ba7c in sb_thread_ctx_key_dtor (pp_ctx=0x4bd5a00) at threadl.cpp:192 #28 0x7fbd39195bc2 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 #29 0x7fbd39195dd3 in start_thread () from /lib64/libpthread.so.0 #30 0x7fbd38899ced in clone () from /lib64/libc.so.6 Core dump in SQL layer is as follows Thread 1 (Thread 0x7fa8421a1a80 (LWP 52446)): #0 0x7fa83f1e05f7 in raise () from /lib64/libc.so.6 #1 0x7fa83f1e1e28 in abort () from /lib64/libc.so.6 #2 0x7fa84107fd99 in os::abort(bool) () from /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so #3 0x7fa841220d06 in VMError::report_and_die() () from /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so #4 0x7fa841088f47 in JVM_handle_linux_signal () from /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so #5 0x7fa84107d1b8 in signalHandler(int, siginfo_t*, void*) () from /usr/lib/jvm/java-1.8.0-openjdk/jre/lib/amd64/server/libjvm.so #6 #7 NAMemory::allocateMemory (this=this@entry=0x7fa700203131, size=size@entry=332, failureIsFatal=failureIsFatal@entry=1) at ../common/NAMemory.cpp:1377 #8 0x7fa84196a2d2 in checkedRealloc (h=0x7fa700203131, newSize=332, dataSize=282, ptr=0x7fa7c7a2b418) at ../export/FBString.h:304 #9 smartRealloc (h=0x7fa700203131, newCapacity=332, currentCapacity=, currentSize=282, p=0x7fa7c7a2b418) at ../export/FBString.h:348 #10 reallocate (h=0x7fa700203131, newCapacity=316, currentCapacity=, currentSize=266, data=0x7fa7c7a2b420 "scan_type: subset scan of table TRAFODION.HBASE.CUSTOMER_DEMOGRAPHICS_SALT object_type: Trafodion cache_size: 1 cache_blocks: OFF probes: 1 rows_accessed: 1e+11 use_snapshot_scan: TRUE full_table"...) at ../export/FBString.h:959 #11 folly::fbstring_core::reserve (this=0x7ffcd30ff480, minCapacity=316) at ../export/FBString.h:655 #12 0x7fa83d9412a7 in expand_noinit (delta=50, this=0x7ffcd30ff480) at ../export/FBString.h:742 #13 append (n=50, s=0x7ffcd30ff451
[jira] [Assigned] (TRAFODION-1165) LP Bug: 1443482 - Accessing hive table with ucs2 encoded field returns 0 rows.
[ https://issues.apache.org/jira/browse/TRAFODION-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-1165: Assignee: liu ming (was: Selvaganesan Govindarajan) Ming can you please confirm if this issue has been already resolved by you > LP Bug: 1443482 - Accessing hive table with ucs2 encoded field returns 0 rows. > -- > > Key: TRAFODION-1165 > URL: https://issues.apache.org/jira/browse/TRAFODION-1165 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Howard Qin >Assignee: liu ming > Labels: hive > Fix For: 2.1-incubating > > > When accessing hive table with ucs2 encoded field, our implementation will > return 0 rows. > This is caused by using of “strchr()”, see > ExHdfsScanTcb::extractAndTransformAsciiSourceToSqlRow(), > strchr() returns at ‘\0’ before hit line delimiter ‘\n’, however the '\0' may > just be a 0x00 part of ucs2 character, and the line is considered invalid. > Scripts to reproduce: > create table sck( > userId int not null, > name varchar(20) character set UCS2 > ); > insert into sck values (1001, _ucs2'JBL'), (1002, _ucs2'YS '), (1003, > _ucs2'8#RTG'); > unload into '/ucs2test' select * from sck; > create external table hsck > ( > id int, > name string > ) row format delimited fields terminated by '|' > location '/ucs2test'; > select * from hive.hive.hsck; > Assigned to LaunchPad User khaled Bouaziz -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (TRAFODION-1546) upsert into table with indexes performs slower than insert
[ https://issues.apache.org/jira/browse/TRAFODION-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-1546: Assignee: Sandhya Sundaresan (was: Selvaganesan Govindarajan) Assigning to Sandhya because she has taken over a similar JIRA > upsert into table with indexes performs slower than insert > -- > > Key: TRAFODION-1546 > URL: https://issues.apache.org/jira/browse/TRAFODION-1546 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Selvaganesan Govindarajan >Assignee: Sandhya Sundaresan > Attachments: query.out, query.sql, setup.sql > > Original Estimate: 1m > Remaining Estimate: 1m > > The plan for upsert and insert are different, but both plans have vsbb > operations enabled for index maintenance. But, it is observed that vsbb > feature kicks in for insert while the upsert command inserts one row at a > time in the index. Hence upsert command performs slower than the insert > command. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (TRAFODION-1139) LP Bug: 1441311 - JDBC query cancel api sometimes tries to cancel repository query and fails
[ https://issues.apache.org/jira/browse/TRAFODION-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-1139: Assignee: Arvind Narain (was: Selvaganesan Govindarajan) Assigning to Arvind to confirm if this issue has been fixed already > LP Bug: 1441311 - JDBC query cancel api sometimes tries to cancel repository > query and fails > > > Key: TRAFODION-1139 > URL: https://issues.apache.org/jira/browse/TRAFODION-1139 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Aruna Sadashiva >Assignee: Arvind Narain >Priority: Critical > Fix For: 2.1-incubating > > > JDBC (and ODBC too) Cancel query api sometimes tries to cancel a repository > query instead of the user query. > org.trafodion.jdbc.t4.HPT4Exception: The message id: ids_program_error With > parameters: *** ERROR[8031] Server declined cancel request for query ID > MXID110030206712122951602734954760306U300_29_STMT_PUBLICATION. > The query is not in OPEN or FETCH or EXECUTE state. > SQLState HY018 > Error Code -8031 > at > org.trafodion.jdbc.t4.HPT4Messages.createSQLException(HPT4Messages.java:304) > at > org.trafodion.jdbc.t4.HPT4Messages.createSQLException(HPT4Messages.java:238) > at > org.trafodion.jdbc.t4.odbc_Dcs_StopSrvr_exc_.extractFromByteArray(odbc_Dcs_StopSrvr_exc_.java:74) > at org.trafodion.jdbc.t4.CancelReply.(CancelReply.java:33) > at org.trafodion.jdbc.t4.T4_Dcs_Cancel.cancel(T4_Dcs_Cancel.java:89) > at > org.trafodion.jdbc.t4.InterfaceConnection.cancel(InterfaceConnection.java:478) > at > org.trafodion.jdbc.t4.InterfaceStatement.cancel(InterfaceStatement.java:1044) > at > org.trafodion.jdbc.t4.TrafT4Statement.cancel(TrafT4Statement.java:104) > at qc1$cancelThread.run(qc1.java:139) > SQLMessage The message id: ids_program_error With parameters: *** > ERROR[8031] Server declined cancel request for query ID > MXID110030206712122951602734954760306U300_29_STMT_PUBLICATION. > The query is not in OPEN or FETCH or EXECUTE state. > SQLState HY018 > Error Code -8031 > SQLState HY000 > Error Code -1 > Got SQLException in queryThread. > org.trafodion.jdbc.t4.HPT4Exception: The message id: invalid_cursor_state > at > org.trafodion.jdbc.t4.HPT4Messages.createSQLException(HPT4Messages.java:304) > at > org.trafodion.jdbc.t4.TrafT4ResultSet.getType(TrafT4ResultSet.java:2369) > at > org.trafodion.jdbc.t4.TrafT4ResultSet.setFetchOutputs(TrafT4ResultSet.java:4597) > at > org.trafodion.jdbc.t4.InterfaceResultSet.setExecute2FetchOutputs(InterfaceResultSet.java:729) > at > org.trafodion.jdbc.t4.InterfaceResultSet.fetch(InterfaceResultSet.java:796) > at org.trafodion.jdbc.t4.TrafT4ResultSet.next(TrafT4ResultSet.java:2870) > at qc1$queryThread.run(qc1.java:76) > SQLMessage The message id: invalid_cursor_state > SQLState HY000 > Error Code -1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-926) LP Bug: 1413400 - HDFS scan operator may not always return diags info with error entry
[ https://issues.apache.org/jira/browse/TRAFODION-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-926. - Resolution: Duplicate This issue has been addressed as part of enhancing bulk load in Trafodon. See https://issues.apache.org/jira/browse/TRAFODION-2351?filter=-3 > LP Bug: 1413400 - HDFS scan operator may not always return diags info with > error entry > -- > > Key: TRAFODION-926 > URL: https://issues.apache.org/jira/browse/TRAFODION-926 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: justin...@hp.com >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > This problem was found when examining the esp core files. The code dump was > due to the reason at these lines in sql/executor/ex_tuple_flow.cpp: > 349 ComDiagsArea * da = src_entry->getDiagsArea(); > 350 ex_assert(da, "We have a Q_SQLERROR in > Tupleflow but no diags area"); > 351 > Further analysis indicates that ExHdfsScanTcb::work() method inserted the > Q_SQLERROR entry to its parent up queue without attaching the diags area with > it. > When the work method inserts a Q_SQLERROR entry, it expects that the head > entry of the parent down queue contains the diags area, which was populated > in other steps prior to the HANDLE_ERROR step, or the workAtp_ should have > one. Otherwise, it could return that entry without populated the atp_ diags > area of the entry. > The more suspicious area is at line 820 of sql/executor/ExHdfsScan.cpp when > ExHdfsScanTcb::extractAndTransformAsciiSourceToSqlRow() call returns error > but without populating the diagsArea of workAtp_. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-1913) org.trafodion.jdbc.t4 throws an error
[ https://issues.apache.org/jira/browse/TRAFODION-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-1913. -- Resolution: Fixed Fix Version/s: 2.1-incubating > org.trafodion.jdbc.t4 throws an error > -- > > Key: TRAFODION-1913 > URL: https://issues.apache.org/jira/browse/TRAFODION-1913 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 1.3-incubating >Reporter: Pierre Smits >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > Attachments: hs_err_pid50530.log > > > See this thread: http://trafodion.markmail.org/message/iuu7jntaykmhotuz > After a restart of both the Trafodion 1.3 Sandbox and Apache ofbiz I get the > subject of this posting returned in the OFBiz log. The excerpt shows: > [java] Caused by: org.trafodion.jdbc.t4.HPT4Exception: The message id: > problem_with_server_read > [java] at > org.trafodion.jdbc.t4.HPT4Messages.createSQLException(HPT4Messages.java:304) > ~[jdbcT4.jar:?] > [java] at org.trafodion.jdbc.t4.InputOutput.doIO(InputOutput.java:373) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.T4Connection.getReadBuffer(T4Connection.java:154) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.T4Connection.EndTransaction(T4Connection.java:398) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.InterfaceConnection.endTransaction(InterfaceConnection.java:1222) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.InterfaceConnection.rollback(InterfaceConnection.java:440) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.TrafT4Connection.rollback(TrafT4Connection.java:1025) > ~[jdbcT4.jar:?] > This continued multiple times until the OFBiz instantiation halts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TRAFODION-1913) org.trafodion.jdbc.t4 throws an error
[ https://issues.apache.org/jira/browse/TRAFODION-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15874813#comment-15874813 ] Selvaganesan Govindarajan commented on TRAFODION-1913: -- Pierre, I should have updated this JIRA much earlier. This issue was internally pursued by Esgyn team Prashanth Vasudev, Wei-shiun and I. This issue has been fixed. I will gather the PRs that fixed this issue and update it here > org.trafodion.jdbc.t4 throws an error > -- > > Key: TRAFODION-1913 > URL: https://issues.apache.org/jira/browse/TRAFODION-1913 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 1.3-incubating >Reporter: Pierre Smits >Assignee: Selvaganesan Govindarajan > Attachments: hs_err_pid50530.log > > > See this thread: http://trafodion.markmail.org/message/iuu7jntaykmhotuz > After a restart of both the Trafodion 1.3 Sandbox and Apache ofbiz I get the > subject of this posting returned in the OFBiz log. The excerpt shows: > [java] Caused by: org.trafodion.jdbc.t4.HPT4Exception: The message id: > problem_with_server_read > [java] at > org.trafodion.jdbc.t4.HPT4Messages.createSQLException(HPT4Messages.java:304) > ~[jdbcT4.jar:?] > [java] at org.trafodion.jdbc.t4.InputOutput.doIO(InputOutput.java:373) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.T4Connection.getReadBuffer(T4Connection.java:154) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.T4Connection.EndTransaction(T4Connection.java:398) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.InterfaceConnection.endTransaction(InterfaceConnection.java:1222) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.InterfaceConnection.rollback(InterfaceConnection.java:440) > ~[jdbcT4.jar:?] > [java] at > org.trafodion.jdbc.t4.TrafT4Connection.rollback(TrafT4Connection.java:1025) > ~[jdbcT4.jar:?] > This continued multiple times until the OFBiz instantiation halts. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (TRAFODION-2351) Bulk load with log error rows enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2351. -- Resolution: Fixed Fix Version/s: 2.1-incubating Many issues found with bulk loaded has been resolved via various PRs. See PR associated with this JIRA for details. Missing feature is: Trafodion doesn't support skip/log error rows when the data is bulk loaded from a Trafodion table to another table. > Bulk load with log error rows enhancements > -- > > Key: TRAFODION-2351 > URL: https://issues.apache.org/jira/browse/TRAFODION-2351 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > Bulk load needs the following enhancements > 1) Load with log error rows misses out some error rows being logged > 2) Load with log error rows need to report if there are any error rows > 3) Load with log error rows need to report where the error rows are logged -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (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:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-1959. -- Resolution: Duplicate Fix Version/s: 2.1-incubating Bulk data has been enhanced via JIRA https://issues.apache.org/jira/browse/TRAFODION-2351?filter=-1 This issue has been fixed as part of this enhancement > multiple data file in HDFS will cause bulkloader fail > - > > Key: TRAFODION-1959 > URL: https://issues.apache.org/jira/browse/TRAFODION-1959 > Project: Apache Trafodion > Issue Type: Bug >Reporter: liu ming >Assignee: Selvaganesan Govindarajan > Fix For: 2.1-incubating > > > reported by users several times, but I need to design a test. File a jira now > just in case this issue will be out of track. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
