[jira] [Updated] (TRAFODION-1176) LP Bug: 1444549 - DCS floating IP should set internal interface
[ https://issues.apache.org/jira/browse/TRAFODION-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1176: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1444549 - DCS floating IP should set internal interface > --- > > Key: TRAFODION-1176 > URL: https://issues.apache.org/jira/browse/TRAFODION-1176 > Project: Apache Trafodion > Issue Type: Improvement > Components: connectivity-dcs >Reporter: Matt Brown >Assignee: Arvind Narain >Priority: Major > Fix For: 2.4 > > > DCS currently has the following properties for floating IP: > /** DcsMaster Floating IP external IP address */ > public static final String DCS_MASTER_FLOATING_IP_EXTERNAL_IP_ADDRESS = > "dcs.master.floating.ip.external.ip.address"; > /** Default DcsMaster Floating IP external IP address */ > public static final String > DEFAULT_DCS_MASTER_FLOATING_IP_EXTERNAL_IP_ADDRESS = "default"; > Need to add more properties for internal interface e.g., > /** DcsMaster Floating IP internal IP address */ > public static final String DCS_MASTER_FLOATING_IP_INTERNAL_IP_ADDRESS = > "dcs.master.floating.ip.internal.ip.address"; > /** Default DcsMaster Floating IP internal IP address */ > public static final String > DEFAULT_DCS_MASTER_FLOATING_IP_INTERNAL_IP_ADDRESS = "default"; > DcsMaster can then invoke dcsbind.sh for both -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1112) LP Bug: 1438888 - Error message incorrect when describing non existing procedure
[ https://issues.apache.org/jira/browse/TRAFODION-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1112: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 143 - Error message incorrect when describing non existing > procedure > > > Key: TRAFODION-1112 > URL: https://issues.apache.org/jira/browse/TRAFODION-1112 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-security >Reporter: Paul Low >Assignee: Suresh Subbiah >Priority: Minor > Fix For: 2.4 > > > Minor issue. > Users may be confused by the error message that returns when trying to > execute 'showddl procedure T1' when T1 is not a procedure. > T1 does not exist as a procedure, but T1 does exist as a table object. > The text in the error message is technically incorrect because object T1 does > exist, just not as a procedure. > SQL>create schema schema1; > --- SQL operation complete. > SQL>set schema schema1; > --- SQL operation complete. > SQL>create table t1 (c1 int not null primary key, c2 int); > --- SQL operation complete. > SQL>grant select on table t1 to qauser_sqlqaa; > --- SQL operation complete. > SQL>showddl procedure t1; > *** ERROR[1389] Object T1 does not exist in Trafodion. > *** ERROR[4082] Object TRAFODION.SCHEMA1.T1 does not exist or is inaccessible > SQL>drop schema schema1 cascade; > --- SQL operation complete. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1173) LP Bug: 1444088 - Hybrid Query Cache: sqlci may err with JRE SIGSEGV.
[ https://issues.apache.org/jira/browse/TRAFODION-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1173: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1444088 - Hybrid Query Cache: sqlci may err with JRE SIGSEGV. > - > > Key: TRAFODION-1173 > URL: https://issues.apache.org/jira/browse/TRAFODION-1173 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Julie Thai >Assignee: Suresh Subbiah >Priority: Major > Fix For: 2.4 > > > In sqlci, with HQC on and HQC_LOG specified, a prepared statement was > followed with: > >>--interval 47, same selectivity as interval 51 > >>--interval 47 [jvFN3&789 - jyBT!]789) > >>--expect = nothing in hqc log; SQC hit > >>prepare XX from select * from f00 where colchar = 'jyBT!]789'; > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x75d80595, pid=2708, tid=140737353866272 > # > # JRE version: Java(TM) SE Runtime Environment (7.0_75-b13) (build > 1.7.0_75-b13) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.75-b04 mixed mode > linux-amd64 compressed oops) > # Problematic frame: > # C [libstdc++.so.6+0x91595] > std::ostream::sentry::sentry(std::ostream&)+0x25 > # > # Core dump written. Default location: > /opt/home/trafodion/thaiju/HQC/equal_char/core or core.2708 > # > # An error report file with more information is saved as: > # /opt/home/trafodion/thaiju/HQC/equal_char/hs_err_pid2708.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > Aborted > No core file found under /opt/home/trafodion/thaiju/HQC/equal_char. But a > hs_err_pid2708.log file was generated (included in attached, to_repro.tar). > Problem does not reproduce if I explicitly turn off HQC. > To reproduce: > 1. download and untar attachment, to_repro.tar > 1. in a sqlci session, obey setup_char.sql (from tar file) > 2. in a new sqlci session, obey equal_char.sql (from tar file) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1221) LP Bug: 1450853 - Hybrid Query Cache: query with equals predicate on INTERVAL datatype should not have a non-parameterized literal.
[
https://issues.apache.org/jira/browse/TRAFODION-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-1221:
-
Fix Version/s: (was: 2.3)
2.4
> LP Bug: 1450853 - Hybrid Query Cache: query with equals predicate on INTERVAL
> datatype should not have a non-parameterized literal.
> ---
>
> Key: TRAFODION-1221
> URL: https://issues.apache.org/jira/browse/TRAFODION-1221
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
>Reporter: Julie Thai
>Assignee: Suresh Subbiah
>Priority: Critical
> Fix For: 2.4
>
>
> For query with equal predicate on INTERVAL datatype, both parameterized and
> non-parameterized literals appear in HybridQueryCacheEntries virtual table.
> Non-parametrrized literal should be empty.
> SQL>prepare XX from select * from F00INTVL where colintvl = interval '39998'
> day(6);
> *** WARNING[6008] Statistics for column (COLKEY) from table
> TRAFODION.QUERYCACHE_HQC.F00INTVL were not available. As a result, the access
> path chosen might not be the best possible. [2015-04-30 13:31:48]
> --- SQL command prepared.
> SQL>execute show_entries;
> HKEY
>NUM_HITS NUM_PLITERALS
> (EXPR)
>NUM_NPLITERALS (EXPR)
>
>
> -- -
>
> --
>
> SELECT * FROM F00INTVL WHERE COLINTVL = INTERVAL #NP# DAY ( #NP# ) ;
> 0 1
> INTERVAL '39998' DAY(6)
> 1 '39998'
> --- 1 row(s) selected.
> To reproduce:
> create table F00INTVL(
> colkey int not null primary key,
> colintvl interval day(6));
> load into F00INTVL select
> c1+c2*10+c3*100+c4*1000+c5*1+c6*10, --colkey
> cast(cast(mod(c1+c2*10+c3*100+c4*1000+c5*1+c6*10,99)
> as integer) as interval day(6)) --colintvl
> from (values(1)) t
> transpose 0,1,2,3,4,5,6,7,8,9 as c1
> transpose 0,1,2,3,4,5,6,7,8,9 as c2
> transpose 0,1,2,3,4,5,6,7,8,9 as c3
> transpose 0,1,2,3,4,5,6,7,8,9 as c4
> transpose 0,1,2,3,4,5,6,7,8,9 as c5
> transpose 0,1,2,3,4,5,6,7,8,9 as c6;
> update statistics for table F00INTVL on colintvl;
> prepare show_entries from select left(hkey,50), num_pliterals,
> left(pliterals,15), num_npliterals, left(npliterals,15) from
> table(HybridQueryCacheEntries('USER', 'LOCAL'));
> prepare XX from select * from F00INTVL where colintvl = interval '39998'
> day(6);
> execute show_entries;
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-2348) TransactionState.hasConflict returns true if it gets a null pointer exception
[ https://issues.apache.org/jira/browse/TRAFODION-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2348: - Fix Version/s: (was: 2.3) 2.4 > TransactionState.hasConflict returns true if it gets a null pointer exception > - > > Key: TRAFODION-2348 > URL: https://issues.apache.org/jira/browse/TRAFODION-2348 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Affects Versions: 2.1-incubating, any >Reporter: Sean Broeder >Assignee: Sean Broeder >Priority: Major > Fix For: 2.4 > > > In the middle of hasConflict the TransactionState object compares its > writeOrder list to various other transactions. In this case, we get a Null > pointer exception in the trasnaction to check against, so we return true to > has conflict and the transaction aborts. > 2016-11-07 20:00:28,673 WARN > org.apache.hadoop.hbase.regionserver.transactional.TransactionState: > TrxTransactionState hasConflict: > Unable to get row - this Transaction [[transactionId: 12919375954 regionTX: > false status: PENDING neverReadOnly: false scan Size: 28 write Size: 14 > startSQ: 34310]] > checkAgainst Transaction [[transactionId: 17214542234 regionTX: false status: > ABORTED neverReadOnly: false scan Size: 0 write Size: 0 startSQ: 34296 > commitedSQ:34314]] Exception: > java.lang.NullPointerException > at > org.apache.hadoop.hbase.regionserver.transactional.TrxTransactionState.hasConflict(TrxTransactionState.java:469) > at > org.apache.hadoop.hbase.regionserver.transactional.TrxTransactionState.hasConflict(TrxTransactionState.java:438) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.hasConflict(TrxRegionEndpoint.java:6389) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:6138) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:6077) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:894) > at > org.apache.hadoop.hbase.coprocessor.transactional.generated.TrxRegionProtos$TrxRegionService.callMethod(TrxRegionProtos.java:49510) > at > org.apache.hadoop.hbase.regionserver.HRegion.execService(HRegion.java:7054) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.execServiceOnRegion(RSRpcServices.java:1746) > at > org.apache.hadoop.hbase.regionserver.RSRpcServices.execService(RSRpcServices.java:1728) > at > org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:31447) > at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2035) > at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:107) > at > org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130) > at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107) > at java.lang.Thread.run(Thread.java:745) > 2016-11-07 20:00:28,674 ERROR > org.apache.hadoop.hbase.regionserver.transactional.TransactionState: > TrxTransactionState hasConflict: > Returning true. This transaction [transactionId: 12919375954 regionTX: false > status: PENDING neverReadOnly: false scan Size: 28 write Size: 14 startSQ: > 34310] Caught exception from transaction [transactionId: 17214542234 > regionTX: false status: ABORTED neverReadOnly: false scan Size: 0 write Size: > 0 startSQ: 34296 commitedSQ:34314], regionInfo is > [TRAFODION.JAVABENCH.OE_ORDERLINE_192,\x00\x00\x00\x1D\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00,1478575978122.228b0109fcab4c57c25d7f1326f40f4e.], > exception > java.lang.NullPointerException > at > org.apache.hadoop.hbase.regionserver.transactional.TrxTransactionState.hasConflict(TrxTransactionState.java:469) > at > org.apache.hadoop.hbase.regionserver.transactional.TrxTransactionState.hasConflict(TrxTransactionState.java:438) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.hasConflict(TrxRegionEndpoint.java:6389) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:6138) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:6077) > at > org.apache.hadoop.hbase.coprocessor.transactional.TrxRegionEndpoint.commitRequest(TrxRegionEndpoint.java:894) > at >
[jira] [Updated] (TRAFODION-2472) Alter table hbase options is not transaction enabled.
[ https://issues.apache.org/jira/browse/TRAFODION-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2472: - Fix Version/s: (was: 2.3) 2.4 > Alter table hbase options is not transaction enabled. > - > > Key: TRAFODION-2472 > URL: https://issues.apache.org/jira/browse/TRAFODION-2472 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Reporter: Prashanth Vasudev >Assignee: Prashanth Vasudev >Priority: Major > Fix For: 2.4 > > > Transaction DDL for alter commands is currently disabled. > There are few statements such as alter hbase option that is not disabled > which results in unpredictable errors. > Initially fix would be to disable alter statement to not use DDl transaction. > Following this DDL transaction would be enhanced to support of Alter table > statement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1053) LP Bug: 1430938 - In full explain output, begin/end key for char/varchar key column should be min/max if there is no predicated defined on the key column.
[ https://issues.apache.org/jira/browse/TRAFODION-1053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1053: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1430938 - In full explain output, begin/end key for char/varchar key > column should be min/max if there is no predicated defined on the key column. > -- > > Key: TRAFODION-1053 > URL: https://issues.apache.org/jira/browse/TRAFODION-1053 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Julie Thai >Assignee: Suresh Subbiah >Priority: Major > Fix For: 2.4 > > > In full explain output, begin/end key for char/varchar key column should be > min/max > if there is no predicated defined on the key column. > Snippet from TRAFODION_SCAN below: > key_columns _SALT_, COLTS, COLVCHRUCS2, COLINTS > begin_key .. (_SALT_ = %(9)), (COLTS = ), > (COLVCHRUCS2 = '洼硡'), (COLINTS = > ) > end_key (_SALT_ = %(9)), (COLTS = ), > (COLVCHRUCS2 = '洼湩'), (COLINTS = > ) > Expected (COLVCHRUCS2 = '') and (COLVCHRUCS2 = ''). > SQL>create table salttbl3 ( > +>colintu int unsigned not null, colints int signed not null, > +>colsintu smallint unsigned not null, colsints smallint signed not null, > +>collint largeint not null, colnum numeric(11,3) not null, > +>colflt float not null, coldec decimal(11,2) not null, > +>colreal real not null, coldbl double precision not null, > +>coldate date not null, coltime time not null, > +>colts timestamp not null, > +>colchriso char(90) character set iso88591 not null, > +>colchrucs2 char(111) character set ucs2 not null, > +>colvchriso varchar(113) character set iso88591 not null, > +>colvchrucs2 varchar(115) character set ucs2 not null, > +>PRIMARY KEY (colts ASC, colvchrucs2 DESC, colints ASC)) > +>SALT USING 9 PARTITIONS ON (colints, colvchrucs2, colts); > --- SQL operation complete. > SQL>LOAD INTO salttbl3 SELECT > +>c1+c2*10+c3*100+c4*1000+c5*1, > +>(c1+c2*10+c3*100+c4*1000+c5*1) - 5, > +>mod(c1+c2*10+c3*100+c4*1000+c5*1, 65535), > +>mod(c1+c2*10+c3*100+c4*1000+c5*1, 32767), > +>(c1+c2*10+c3*100+c4*1000+c5*1) + 549755813888, > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as numeric(11,3)), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as float), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as decimal(11,2)), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as real), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as double precision), > +>cast(converttimestamp(2106142992 + > +>(864 * (c1+c2*10+c3*100+c4*1000+c5*1))) as date), > +>time'00:00:00' + cast(mod(c1+c2*10+c3*100+c4*1000+c5*1,3) > +>as interval minute), > +>converttimestamp(2106142992 + (864 * > +>(c1+c2*10+c3*100+c4*1000+c5*1)) + (100 * (c1+c2*10+c3*100)) + > +>(6000 * (c1+c2*10)) + (36 * (c1+c2*10))), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as char(90) character set iso88591), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as char(111) character set ucs2), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as varchar(113) character set > iso88591), > +>cast(c1+c2*10+c3*100+c4*1000+c5*1 as varchar(115) character set ucs2) > +>from (values(1)) t > +>transpose 0,1,2,3,4,5,6,7,8,9 as c1 > +>transpose 0,1,2,3,4,5,6,7,8,9 as c2 > +>transpose 0,1,2,3,4,5,6,7,8,9 as c3 > +>transpose 0,1,2,3,4,5,6,7,8,9 as c4 > +>transpose 0,1,2,3,4,5,6,7,8,9 as c5; > UTIL_OUTPUT > > Task: LOAD Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > > Task: CLEANUP Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > > Task: CLEANUP Status: Ended Object: TRAFODION.SEABASE.SALTTBL3 > > Task: DISABLE INDEXE Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > > Task: DISABLE INDEXE Status: Ended Object: TRAFODION.SEABASE.SALTTBL3 > > Task: PREPARATION Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > >Rows Processed: 10 > Task: PREPARATION Status: Ended ET: 00:00:10.332 > > Task: COMPLETION Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > > Task: COMPLETION Status: Ended ET: 00:00:02.941 > > Task: POPULATE INDEX Status: StartedObject: TRAFODION.SEABASE.SALTTBL3 > > Task: POPULATE INDEX Status: Ended ET: 00:00:05.357 > > --- SQL
[jira] [Updated] (TRAFODION-157) LP Bug: 1252809 - DCS-ODBC-Getting 'Invalid server handle' after bound hstmt is used for a while.
[ https://issues.apache.org/jira/browse/TRAFODION-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-157: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1252809 - DCS-ODBC-Getting 'Invalid server handle' after bound hstmt > is used for a while. > - > > Key: TRAFODION-157 > URL: https://issues.apache.org/jira/browse/TRAFODION-157 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-linux >Reporter: Aruna Sadashiva >Assignee: RuoYu Zuo >Priority: Major > Fix For: 2.4 > > > Using ODBC 64 bit Linux driver. > 'Invalid server handle' is returned and insert fails when using > SQLBindParameter/Prepare/Execute. The SQLExecute is done in a loop. It works > for a while, but fails within 10 minutes. Changed the program to reconnect > every 5 mins, but still seeing this error. It works on SQ. > Have attached simple test program to recreate this. To run on SQ remove the > SQLExecDirect calls to set CQDs, those are specific to Traf. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1246) LP Bug: 1458011 - Change core file names in Sandbox
[ https://issues.apache.org/jira/browse/TRAFODION-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1246: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1458011 - Change core file names in Sandbox > --- > > Key: TRAFODION-1246 > URL: https://issues.apache.org/jira/browse/TRAFODION-1246 > Project: Apache Trafodion > Issue Type: Bug > Components: installer >Reporter: Amanda Moran >Priority: Minor > Fix For: 2.4 > > > When creating a sandbox we should change the name of core files so that users > will not have to do it themselves. > echo "/tmp/cores/core.%e.%p.%h.%t" > /proc/sys/kernel/core_pattern > Reference: https://sigquit.wordpress.com/2009/03/13/the-core-pattern/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2742) Linux and Windows ODBC need to support LOB
[ https://issues.apache.org/jira/browse/TRAFODION-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2742: - Fix Version/s: (was: 2.3) 2.4 > Linux and Windows ODBC need to support LOB > > > Key: TRAFODION-2742 > URL: https://issues.apache.org/jira/browse/TRAFODION-2742 > Project: Apache Trafodion > Issue Type: Technical task > Components: client-jdbc-t4, connectivity-mxosrvr, sql-exe >Reporter: Weiqing Xu >Assignee: Weiqing Xu >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-533) LP Bug: 1355042 - SPJ w result set failed with ERROR[11220], SQLCODE of -29261, SQLSTATE of HY000
[
https://issues.apache.org/jira/browse/TRAFODION-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-533:
Fix Version/s: (was: 2.3)
2.4
> LP Bug: 1355042 - SPJ w result set failed with ERROR[11220], SQLCODE of
> -29261, SQLSTATE of HY000
> -
>
> Key: TRAFODION-533
> URL: https://issues.apache.org/jira/browse/TRAFODION-533
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Chong Hsu
>Assignee: Kevin Xu
>Priority: Critical
> Fix For: 2.4
>
>
> Tested with Trafodion build, 20140801-0830.
> Calling a SPJ that calls another SPJ with result set:
>public static void RS363()
> throws Exception
>{
> String str = "jdbc:default:connection";
>
> Connection localConnection = DriverManager.getConnection(str);
> Statement localStatement = localConnection.createStatement();
>
> CallableStatement localCallableStatement =
> localConnection.prepareCall("{call RS200()}");
> localCallableStatement.execute();
>}
>public static void RS200(ResultSet[] paramArrayOfResultSet)
>throws Exception
>{
> String str1 = "jdbc:default:connection";
>
> String str2 = "select * from t1";
> Connection localConnection = DriverManager.getConnection(str1);
> Statement localStatement = localConnection.createStatement();
> paramArrayOfResultSet[0] = localStatement.executeQuery(str2);
>}
> it failed with ERROR:
> *** ERROR[11220] A Java method completed with an uncaught
> java.sql.SQLException with invalid SQLSTATE. The uncaught exception had a
> SQLCODE of -29261 and SQLSTATE of HY000. Details: java.sql.SQLException: No
> error message in SQL/MX diagnostics area, but sqlcode is non-zero [2014-08-04
> 22:57:28]
> The SPJ Jar file is attached. Here are the steps to produce the error:
>
> set schema testspj;
> create library spjrs file '//Testrs.jar';
> create procedure RS363()
>language java
>parameter style java
>external name 'Testrs.RS363'
>dynamic result sets 0
>library spjrs;
> --- SQL operation complete.
> create procedure RS200()
>language java
>parameter style java
>external name 'Testrs.RS200'
>dynamic result sets 1
>library spjrs;
> create table T1
> (
> AINT DEFAULT NULL
> , BINT DEFAULT NULL
> ) no partitions;
> Call RS363();
> *** ERROR[11220] A Java method completed with an uncaught
> java.sql.SQLException with invalid SQLSTATE. The uncaught exception had a
> SQLCODE of -29261 and SQLSTATE of HY000. Details: java.sql.SQLException: No
> error message in SQL/MX diagnostics area, but sqlcode is non-zero [2014-08-04
> 22:57:28]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-2996) Incorrect copyright year
[ https://issues.apache.org/jira/browse/TRAFODION-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2996: - Fix Version/s: (was: 2.3) 2.4 > Incorrect copyright year > > > Key: TRAFODION-2996 > URL: https://issues.apache.org/jira/browse/TRAFODION-2996 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Minor > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-735) LP Bug: 1388930 - ODBC SQLRowCount function returns wrong row number
[ https://issues.apache.org/jira/browse/TRAFODION-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-735: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1388930 - ODBC SQLRowCount function returns wrong row number > > > Key: TRAFODION-735 > URL: https://issues.apache.org/jira/browse/TRAFODION-735 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-linux >Reporter: JiepingZhang >Assignee: Daniel Lu >Priority: Critical > Fix For: 2.4 > > > In the rowset update test, 10 rows were inserted to the table, hence 10 rows > were expected to be updated, but SQLRowCount returned 55 rows instead. > > Binding parameters. > >> Freeing the statement bind parameter buffers. > > Updating rows. > >> ERROR: The number of expected good rows processed [10] does not match the > SQLRowCount() [55] at line 3457. > tableType[100]: REGULAR > tableFeature[1]: STANDARD > mode[1]: STANDARD > feature[1]: STANDARD > operation[20]: PREPARE_EXECUTE > action[32]: UPDATE > bindOrientation[40]: ROW > injectionType[60]: NO_ERRORS > numberOfRows: 10 > rowsetSize: 10 > commitRate: 1000 > [1] 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1234567890123456789 > 1234567890123456789 > [2] 2 2 2 2 2 2 2 2 1 2 1 1 1 1 1 1 2 2 2 2 2 2 1234567890123456789 > 1234567890123456789 > [3] 3 3 3 3 3 3 3 3 1 3 1 1 1 1 1 1 3 3 3 3 3 2 1234567890123456789 > 1234567890123456789 > [4] 4 4 4 4 4 4 4 4 1 4 1 1 1 1 1 1 4 4 4 4 4 2 1234567890123456789 > 1234567890123456789 > [5] 5 5 5 5 5 5 5 5 1 5 1 1 1 1 1 1 5 5 5 5 5 2 1234567890123456789 > 1234567890123456789 > [6] 6 6 6 6 6 6 6 6 1 6 1 1 1 1 1 1 6 6 6 6 6 2 1234567890123456789 > 1234567890123456789 > [7] 7 7 7 7 7 7 7 7 1 7 1 1 1 1 1 1 7 7 7 7 7 2 1234567890123456789 > 1234567890123456789 > [8] 8 8 8 8 8 8 8 8 1 8 1 1 1 1 1 1 8 8 8 8 8 2 1234567890123456789 > 1234567890123456789 > [9] 9 9 9 9 9 9 9 9 1 9 1 1 1 1 1 1 9 9 9 9 9 2 1234567890123456789 > 1234567890123456789 > [10] 10 10 10 10 10 10 10 10 1 10 1 1 1 1 1 1 10 10 10 10 10 2 > 1234567890123456789 1234567890123456789 > FAILED! > > Free handles. > >>showddl rowset_table; > CREATE TABLE TRAFODION.ODBCTEST.ROWSET_TABLE > ( > C01 CHAR(20) CHARACTER SET ISO88591 COLLATE > DEFAULT NO DEFAULT NOT NULL NOT DROPPABLE > , C02 CHAR(20) CHARACTER SET UCS2 COLLATE > DEFAULT DEFAULT NULL > , C03 VARCHAR(20) CHARACTER SET ISO88591 > COLLATE > DEFAULT DEFAULT NULL > , C04 VARCHAR(20) CHARACTER SET UCS2 COLLATE > DEFAULT DEFAULT NULL > , C05 VARCHAR(20) CHARACTER SET ISO88591 > COLLATE > DEFAULT DEFAULT NULL > , C06 VARCHAR(20) CHARACTER SET UCS2 COLLATE > DEFAULT DEFAULT NULL > , C07 CHAR(20) CHARACTER SET UCS2 COLLATE > DEFAULT DEFAULT NULL > , C08 VARCHAR(20) CHARACTER SET UCS2 COLLATE > DEFAULT DEFAULT NULL > , C09 DECIMAL(8, 0) DEFAULT NULL > , C10 DECIMAL(8, 0) UNSIGNED DEFAULT NULL > , C11 NUMERIC(8, 0) DEFAULT NULL > , C12 NUMERIC(8, 0) UNSIGNED DEFAULT NULL > , C13 SMALLINT DEFAULT NULL > , C14 SMALLINT UNSIGNED DEFAULT NULL > , C15 SMALLINT DEFAULT NULL > , C16 SMALLINT UNSIGNED DEFAULT NULL > , C17 INT NO DEFAULT NOT NULL NOT DROPPABLE > , C18 INT UNSIGNED DEFAULT NULL > , C19 LARGEINT NO DEFAULT NOT NULL NOT > DROPPABLE > , C20 REAL DEFAULT NULL > , C21 DOUBLE PRECISION DEFAULT NULL > , C22 DOUBLE PRECISION DEFAULT NULL > , C23 DATE DEFAULT NULL > , C24 TIME(0) DEFAULT NULL > , C25 TIMESTAMP(6) DEFAULT NULL > , C26 INTERVAL YEAR(2) DEFAULT NULL > , C27 INTERVAL MONTH(2) DEFAULT NULL > , C28 INTERVAL DAY(2) DEFAULT NULL > , C29 INTERVAL HOUR(2) DEFAULT NULL > , C30 INTERVAL MINUTE(2) DEFAULT NULL > , C31 INTERVAL SECOND(2,6) DEFAULT NULL > , C32
[jira] [Updated] (TRAFODION-1267) LP Bug: 1463340 - java.sql.SQLException: *** ERROR[8402] A string overflow occurred during the evaluation of a character expression. Conversion of Source Type:NCHAR V
[
https://issues.apache.org/jira/browse/TRAFODION-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-1267:
-
Fix Version/s: (was: 2.3)
2.4
> LP Bug: 1463340 - java.sql.SQLException: *** ERROR[8402] A string overflow
> occurred during the evaluation of a character expression. Conversion of
> Source Type:NCHAR VARYING(REC_NCHAR_V_UNICODE,96000 BYTES,UTF8) Source Value
> ---
>
> Key: TRAFODION-1267
> URL: https://issues.apache.org/jira/browse/TRAFODION-1267
> Project: Apache Trafodion
> Issue Type: Bug
> Components: client-jdbc-t2
>Reporter: YuBo
>Assignee: Weiqing Xu
>Priority: Major
> Fix For: 2.4
>
>
> Defect Description:
> When insert UCS2 charset with 32K or 200K column length, an error
> "java.sql.SQLException: *** ERROR[8402] A string overflow occurred during the
> evaluation of a character expression. Conversion of Source Type:NCHAR
> VARYING(REC_NCHAR_V_UNICODE,96000 BYTES,UTF8) Source Value" will be happened.
> Test Environment:
> codes' version: commit 1c7265ab7addcd088151904b9139337a29a52d90
> Test Steps:
> Step 1. create a table.
> 405 sql = "create table tblcolumnsize32kWithUCS2(c1 char(16000)
> character set UCS2 collate default null, c2 char(16000) character set UCS2
> collate default null)";
> Step 2. insert UCS2 sql text.
> 409 String a = "";
> 410 String b = "";
> 411
> 412 for (int i = 1; i < 16000; i++) {
> 413 //a += URLEncoder.encode("a", "UTF-16BE");
> 414 //b += URLEncoder.encode("b", "UTF-16BE");
> 415 a += new String("a".getBytes(), "UTF-16BE");
> 416 b += new String("b".getBytes(), "UTF-16BE");
> 417 }
> 418
> 419 //a += URLEncoder.encode("E", "UTF-16BE");
> 420 //b += URLEncoder.encode("E", "UTF-16BE");
> 421 a += new String("E".getBytes(), "UTF-16BE");
> 422 b += new String("E".getBytes(), "UTF-16BE");
> 423
> 424 sql = "insert into tblcolumnsize32kWithUCS2(c1, c2) values('" + a
> + "', '" + b +"')";
> 425 iRet = stmt.executeUpdate(sql);
> 426 assertEquals(1, iRet);
> in the step 2, there is an error happened when execute the line 425, here is
> the console output:
> -bash-4.1$ java -Dprop=t2prop TestBigColumnSize
> Jun 09, 2015 9:49:58 AM TestBigColumnSize
> INFO: = START ALL TEST CASES =
> ---
> SLF4J: Class path contains multiple SLF4J bindings.
> SLF4J: Found binding in
> [jar:file:/opt/home/yubo/trafodion/sqf/sql/local_hadoop/hbase-0.98.6-cdh5.3.0/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: Found binding in
> [jar:file:/opt/home/yubo/trafodion/sqf/sql/local_hadoop/hadoop-2.5.0-cdh5.3.0/share/hadoop/common/lib/slf4j-log4j12-1.7.5.jar!/org/slf4j/impl/StaticLoggerBinder.class]
> SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an
> explanation.
> SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
> java.sql.SQLException: *** ERROR[8402] A string overflow occurred during the
> evaluation of a character expression. Conversion of Source Type:NCHAR
> VARYING(REC_NCHAR_V_UNICODE,96000 BYTES,UTF8) Source
> Value:����������������ï¿
> *** ERROR[8402] A string overflow occurred during the evaluation of a
> character expression. Conversion of Source Type:NCHAR
> VARYING(REC_NCHAR_V_UNICODE,96000 BYTES,UTF8) Source
> Value:����������������ï¿
> java.sql.SQLException: *** ERROR[8402] A string overflow occurred during the
> evaluation of a character expression. Conversion of Source Type:NCHAR
> VARYING(REC_NCHAR_V_UNICODE,96000 BYTES,UTF8) Source
> Value:����������������ï¿
> at org.trafodion.jdbc.t2.SQLMXStatement.executeDirect(Native Method)
> at
> org.trafodion.jdbc.t2.SQLMXStatement.executeUpdate(SQLMXStatement.java:461)
> at
> TestBigColumnSize.test$32KColSizeWithUCS2(TestBigColumnSize.java:425)
> at TestBigColumnSize.main(TestBigColumnSize.java:21)
> ---
> java.sql.SQLException: *** ERROR[8402] A string overflow occurred during the
> evaluation of a character expression. Conversion of Source Type:NCHAR
> VARYING(REC_NCHAR_V_UNICODE,60 BYTES,UTF8) Source
> Value:����������������ï¿
> *** ERROR[8402]
[jira] [Updated] (TRAFODION-2305) After a region split the transactions to check against list is not fully populated
[ https://issues.apache.org/jira/browse/TRAFODION-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2305: - Fix Version/s: (was: 2.3) 2.4 > After a region split the transactions to check against list is not fully > populated > -- > > Key: TRAFODION-2305 > URL: https://issues.apache.org/jira/browse/TRAFODION-2305 > Project: Apache Trafodion > Issue Type: Bug > Components: dtm >Affects Versions: any >Reporter: Sean Broeder >Assignee: Sean Broeder >Priority: Major > Fix For: 2.4 > > > As part of a region split all current transactions and their relationships to > one another are written out into a ZKNode entry and later read in by the > daughter regions. However, the transactionsToCheck list is not correctly > populated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2545) SQL POM file needs changes to be able to stage on Nexus repository
[ https://issues.apache.org/jira/browse/TRAFODION-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2545: - Fix Version/s: (was: 2.3) 2.4 > SQL POM file needs changes to be able to stage on Nexus repository > --- > > Key: TRAFODION-2545 > URL: https://issues.apache.org/jira/browse/TRAFODION-2545 > Project: Apache Trafodion > Issue Type: Task > Components: sql-general >Reporter: Sandhya Sundaresan >Assignee: Prashanth Vasudev >Priority: Major > Fix For: 2.4 > > > The SQL POM file nees change to the PM file similar to what was done in PR : > ALso need to change group id to : > org.apache.trafodion.sql > This will enable us to stage the SQL JAR on Nexus. > Apache NOTICE and LICENSE files need to be packaged in to the SQL JAR too. > According to apache rules "NOTICE and LICENSE files should be present in the > META-INF directory within the jar " -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2907) Remove usage of TRAF_EXCLUDE_LIST
[ https://issues.apache.org/jira/browse/TRAFODION-2907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2907: - Fix Version/s: (was: 2.3) 2.4 > Remove usage of TRAF_EXCLUDE_LIST > -- > > Key: TRAFODION-2907 > URL: https://issues.apache.org/jira/browse/TRAFODION-2907 > Project: Apache Trafodion > Issue Type: Task > Components: foundation >Affects Versions: 2.3 >Reporter: Zalo Correa >Assignee: Zalo Correa >Priority: Minor > Fix For: 2.4 > > > The usage of TRAF_EXCLUDE_LIST nodes is obsolete since the introduction of > TRAFODION-2001. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3016) windows odbc driver add support UTF8 output
[ https://issues.apache.org/jira/browse/TRAFODION-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3016: - Fix Version/s: (was: 2.3) 2.4 > windows odbc driver add support UTF8 output > --- > > Key: TRAFODION-3016 > URL: https://issues.apache.org/jira/browse/TRAFODION-3016 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-windows >Affects Versions: 2.3 > Environment: Client Windows 7 > Server Centos 6.7 >Reporter: XuWeixin >Assignee: XuWeixin >Priority: Major > Fix For: 2.4 > > > The Chinese encode of windows is GBK. > So driver will convert the Chinese characters to GB2312. > But when UTF-8 is needed, it is not supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1442) Linux ODBC Driver is not able to create certificate file with long name length (over 30 bytes).
[ https://issues.apache.org/jira/browse/TRAFODION-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1442: - Fix Version/s: (was: 2.3) 2.4 > Linux ODBC Driver is not able to create certificate file with long name > length (over 30 bytes). > --- > > Key: TRAFODION-1442 > URL: https://issues.apache.org/jira/browse/TRAFODION-1442 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-linux >Affects Versions: 2.0-incubating > Environment: Linunx >Reporter: RuoYu Zuo >Assignee: RuoYu Zuo >Priority: Critical > Fix For: 2.4 > > > Same as Windows driver does, Linux driver also reserved only 30 bytes for > certificate file name, there's potential of running into crash. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-427) LP Bug: 1339541 - windows ODBC driver internal hp keyword cleanup
[ https://issues.apache.org/jira/browse/TRAFODION-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-427: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1339541 - windows ODBC driver internal hp keyword cleanup > - > > Key: TRAFODION-427 > URL: https://issues.apache.org/jira/browse/TRAFODION-427 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-windows >Reporter: Daniel Lu >Assignee: Daniel Lu >Priority: Major > Fix For: 2.4 > > > windows ODBC driver still have some code internally use hp keyword. > for example: > E:\win-odbc64\odbcclient\drvr35\drvrglobal.h(99):#define ODBC_RESOURCE_DLL >"hp_ores0300.dll" > E:\win-odbc64\odbcclient\drvr35adm\drvr35adm.def(10):DESCRIPTION 'hp_oadm > Windows Dynamic Link Library' > E:\win-odbc64\odbcclient\Drvr35Res\Drvr35Res.def(3):LIBRARY > "hp_ores0300" > E:\win-odbc64\odbcclient\Drvr35Res\Drvr35Res.def(4):DESCRIPTION > 'hp_ores0300 Windows Dynamic Link Library' > E:\win-odbc64\odbcclient\drvr35\TCPIPV4\TCPIPV4.def(8):LIBRARY > "hp_tcpipv40300" > E:\win-odbc64\odbcclient\TranslationDll\TranslationDll.def(10):LIBRARY > hp_translation03 > E:\win-odbc64\odbcclient\drvr35\TCPIPV6\TCPIPV6.def(8):LIBRARY > "hp_tcpipv60300" > E:\win-odbc64\Install\UpdateDSN\UpdateDSN\UpdateDSN.cpp(161):// > wcscat_s(NewDriver,L"\\hp_odbc0200.dll"); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2737) Native hbase table access via Trafodion improvements/issues
[ https://issues.apache.org/jira/browse/TRAFODION-2737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2737: - Fix Version/s: (was: 2.3) 2.4 > 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 >Priority: Major > Fix For: 2.4 > > > 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 (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3200) Docker files should show correct version
[ https://issues.apache.org/jira/browse/TRAFODION-3200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3200: - Fix Version/s: (was: 2.3) 2.4 > Docker files should show correct version > > > Key: TRAFODION-3200 > URL: https://issues.apache.org/jira/browse/TRAFODION-3200 > Project: Apache Trafodion > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.4 > > > Currently files under /tools/docker show have parameters that show incorrect > values. > * DOCKER_ENV_VERSION > * version -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3190) expression involving NULL treated as TRUE.
[
https://issues.apache.org/jira/browse/TRAFODION-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-3190:
-
Fix Version/s: (was: 2.3)
2.4
> expression involving NULL treated as TRUE.
> --
>
> Key: TRAFODION-3190
> URL: https://issues.apache.org/jira/browse/TRAFODION-3190
> Project: Apache Trafodion
> Issue Type: Bug
> Components: -exe
>Affects Versions: 2.2.0
>Reporter: Wenjun Zhu
>Assignee: Wenjun Zhu
>Priority: Minor
> Fix For: 2.4
>
>
> expression involving NULL should be treated as FALSE, not TRUE.
>
> like this:
>
> {code:java}
> select case when cast(null as int) > 0 then 1/0 else 0 end from dual;{code}
>
> should output 0, not a Division by zero error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-994) LP Bug: 1420523 - ODBC: Several values returned by SQLColumns are incorrect
[ https://issues.apache.org/jira/browse/TRAFODION-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-994: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1420523 - ODBC: Several values returned by SQLColumns are incorrect > --- > > Key: TRAFODION-994 > URL: https://issues.apache.org/jira/browse/TRAFODION-994 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-general >Reporter: JiepingZhang >Priority: Critical > Fix For: 2.4 > > > Below are the failures in SQLColumn API testing: > 1. In the resultset returned by SQLColumn API, value of column ColNullable is > 2 rather than 1, column REMARK is empty. > Test create table =>create table GTN2BSG5FQ (KXE2QSC7HC char(10) CHARACTER > SET ISO88591) no partition > === > SQLColumns: compare results of columns fetched for following column > The Column Name is KXE2QSC7HC and column type is char > ***ERROR: ColNullable expect: 1 and actual: 2 are not matched > ***ERROR: Remark expect: CHARACTER CHARACTER SET ISO88591 and actual: are > not matched > Number of rows fetched: 1 > 2. Somehow if the table has more than 3 columns, the 3rd column seems got > lost as nothing regarding the 3rd column is returned in the resultset. For > test case below, 3rd column E5IPGXAHNB has no info in the resultset. > 19:18:38 Test create table =>create table GTN2BSG5FQ (KXE2QSC7HC char(10) > CHARACTER SET ISO88591,RMSYLIFAR4 varchar(10) CHARACTER SET > ISO88591,E5IPGXAHNB long varchar CHARACTER SET ISO88591,ZQW9LNYDG3 > decimal(10,5)) no partition > === > 19:18:40 SQLColumns: Test #3 > SQLColumns: SQLColumns function call executed correctly. > SQLColumns: compare results of columns fetched for following column > The Column Name is KXE2QSC7HC and column type is char > ***ERROR: ColNullable expect: 1 and actual: 2 are not matched > ***ERROR: Remark expect: CHARACTER CHARACTER SET ISO88591 and actual: are not > matched > SQLColumns: compare results of columns fetched for following column > The Column Name is RMSYLIFAR4 and column type is varchar > ***ERROR: ColNullable expect: 1 and actual: 2 are not matched > ***ERROR: Remark expect: VARCHAR CHARACTER SET ISO88591 and actual: are not > matched > SQLColumns: compare results of columns fetched for following column > The Column Name is E5IPGXAHNB and column type is long varchar > ***ERROR: ColName expect: E5IPGXAHNB and actual: ZQW9LNYDG3 are not matched > ***ERROR: ColDataType expect: 12 and actual: 3 are not matched > ***ERROR: ColTypeName expect: VARCHAR and actual: DECIMAL are not matched > ***ERROR: ColPrec expect: 2000 and actual: 10 are not matched > ***ERROR: ColLen expect: 2000 and actual: 12 are not matched > ***ERROR: ColScale expect: 0 and actual: 5 are not matched > ***ERROR: ColRadix expect: 0 and actual: 10 are not matched > ***ERROR: ColNullable expect: 1 and actual: 2 are not matched > ***ERROR: Remark expect: VARCHAR CHARACTER SET ISO88591 and actual: are not > matched > Number of rows fetched: 3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2774) Show detail error message in master_exec_xxx.log
[ https://issues.apache.org/jira/browse/TRAFODION-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2774: - Fix Version/s: (was: 2.3) 2.4 > Show detail error message in master_exec_xxx.log > > > Key: TRAFODION-2774 > URL: https://issues.apache.org/jira/browse/TRAFODION-2774 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t4 >Affects Versions: 2.2.0, any >Reporter: Yuan Liu >Priority: Major > Fix For: any, 2.4 > > > When we transfer data from other DB such as Oracle to Trafodion using > third-party tool(Kettle,Embulk,..), if error happens, we can not see detail > error message from server log. > For example, the data type mismatch of correspond columns issue, in ETL tool > we can only see error like "BatchUpdateException", but we can not see detail > error message even from server side, so we should make some enhancement that > shows the detail error message in master_exec_xxx.log. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2779) Unexpected assert when retrieving the current users roles
[ https://issues.apache.org/jira/browse/TRAFODION-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2779: - Fix Version/s: (was: 2.3) 2.4 > Unexpected assert when retrieving the current users roles > - > > Key: TRAFODION-2779 > URL: https://issues.apache.org/jira/browse/TRAFODION-2779 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-security >Affects Versions: 2.2.0 >Reporter: Roberta Marton >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1801) Inserting NULL for all key columns in a table causes a failure
[ https://issues.apache.org/jira/browse/TRAFODION-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1801: - Fix Version/s: (was: 2.3) 2.4 > Inserting NULL for all key columns in a table causes a failure > -- > > Key: TRAFODION-1801 > URL: https://issues.apache.org/jira/browse/TRAFODION-1801 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 1.2-incubating >Reporter: Suresh Subbiah >Assignee: Suresh Subbiah >Priority: Major > Fix For: 2.4 > > > cqd allow_nullable_unique_key_constraint 'on' ; > >>create table t1 (a int, b int, primary key (a,b)) ; > --- SQL operation complete. > >>showddl t1 ; > CREATE TABLE TRAFODION.JIRA.T1 > ( > AINT DEFAULT NULL SERIALIZED > , BINT DEFAULT NULL SERIALIZED > , PRIMARY KEY (A ASC, B ASC) > ) > ; > --- SQL operation complete. > >>insert into t1(a) values (1); > --- 1 row(s) inserted. > >>insert into t1(b) values (2) ; > --- 1 row(s) inserted. > >>select * from t1 ; > AB > --- --- > 1? > ?2 > --- 2 row(s) selected. > >>insert into t1(a) values(3) ; > --- 1 row(s) inserted. > >>select * from t1 ; > AB > --- --- > 1? > 3? > ?2 > --- 3 row(s) selected. > -- fails > >>insert into t1 values (null, null) ; > *** ERROR[8448] Unable to access Hbase interface. Call to > ExpHbaseInterface::checkAndInsertRow returned error HBASE_ACCESS_ERROR(-706). > Cause: > org.apache.hadoop.hbase.client.RetriesExhaustedException: Failed after > attempts=35, exceptions: > Tue Feb 02 19:58:34 UTC 2016, > org.apache.hadoop.hbase.client.RpcRetryingCaller@4c2e0b96, > java.io.IOException: com.google.protobuf.ServiceException: > java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1212) LP Bug: 1449732 - Drop schema cascade returns error 1069
[ https://issues.apache.org/jira/browse/TRAFODION-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1212: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1449732 - Drop schema cascade returns error 1069 > > > Key: TRAFODION-1212 > URL: https://issues.apache.org/jira/browse/TRAFODION-1212 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmu >Reporter: Weishiun Tsai >Assignee: Suresh Subbiah >Priority: Critical > Fix For: 2.4 > > > The frequency of ‘drop schema cascade’ returning error 1069 is still pretty > high, even after several attempts to address this issue. This is causing a > lot of headache for the QA regression testing. After each regression testing > run, there are always several schemas that couldn’t be dropped and needed to > be manually cleaned up. > Multiple issues may lead to this problem. This just happens to be one > scenario that is quite reproducible now. In this particular scenario, the > schema contains a TMUDF library qaTmudfLib and 2 TMUDF functions qa_tmudf1 > and qa_tmudf2. qa_tmudf1 is a valid function, while qa_tmudf2 has a bogus > external name and a call to it is expected to see an error. > After invoking both, a drop schema cascade almost always returns error 1069. > This is seen on the r1.1.0rc3 (v0427) build installed on a workstation and it > is fairly reproducible with this build. To reproduce it: > (1) Download the attached tar file and untar it to get the 3 files in there. > Put the files in any directory . > (2) Make sure that you have run ./sqenv.sh of your Trafodion instance first > as building UDF needs $MY_SQROOT for the header files. > (3) Run build.sh > (4) Change the line “create library qaTmudfLib file > '/qaTMUdfTest.so';” in mytest.sql and fill in > (5) From sqlci, obey mytest.sql > Here is the execution output: > >>log mytest.log clear; > >>drop schema mytest cascade; > *** ERROR[1003] Schema TRAFODION.MYTEST does not exist. > --- SQL operation failed with errors. > >>create schema mytest; > --- SQL operation complete. > >>set schema mytest; > --- SQL operation complete. > >> > >>create library qaTmudfLib file '/qaTMUdfTest.so'; > --- SQL operation complete. > >> > >>create table mytable (a int, b int); > --- SQL operation complete. > >>insert into mytable values (1,1),(2,2); > --- 2 row(s) inserted. > >> > >>create table_mapping function qa_tmudf1() > +>external name 'QA_TMUDF' > +>language cpp > +>library qaTmudfLib; > --- SQL operation complete. > >> > >>select * from UDF(qa_tmudf1(TABLE(select * from mytable))); > AB > --- --- > 11 > 22 > --- 2 row(s) selected. > >> > >>create table_mapping function qa_tmudf2() > +>external name 'DONTEXIST' > +>language cpp > +>library qaTmudfLib; > --- SQL operation complete. > >> > >>select * from UDF(qa_tmudf2(TABLE(select * from mytable))); > *** ERROR[11246] An error occurred locating function 'DONTEXIST' in library > 'qaTMUdfTest.so'. > *** ERROR[8822] The statement was not prepared. > >> > >>drop schema mytest cascade; > *** ERROR[1069] Schema TRAFODION.MYTEST could not be dropped. > --- SQL operation failed with errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1923) executor/TEST106 hangs at drop table at times
[ https://issues.apache.org/jira/browse/TRAFODION-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1923: - Fix Version/s: (was: 2.3) 2.4 > executor/TEST106 hangs at drop table at times > - > > Key: TRAFODION-1923 > URL: https://issues.apache.org/jira/browse/TRAFODION-1923 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: 2.0-incubating >Reporter: Selvaganesan Govindarajan >Assignee: Prashanth Vasudev >Priority: Critical > Fix For: 2.4 > > > executor/TEST106 hangs at > drop table t106a > Currently executor/TEST106 test is not run as part of Daily regression build. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1145) LP Bug: 1441784 - UDF: Lack of checking for scalar UDF input/output values
[ https://issues.apache.org/jira/browse/TRAFODION-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1145: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1441784 - UDF: Lack of checking for scalar UDF input/output values > -- > > Key: TRAFODION-1145 > URL: https://issues.apache.org/jira/browse/TRAFODION-1145 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Weishiun Tsai >Assignee: Suresh Subbiah >Priority: Critical > Fix For: 2.4 > > Attachments: udf_bug (1).tar > > > Ideally, input/output values for a scalar UDF should be verified at the > create function time. But this check is not in place right now. As a > result, a lot of ill-constructed input/output values are left to be handled > at the run time. And the behavior at the run time is haphazard at best. > Here shows 3 examples of such behavior: > (a) myudf1 defines 2 input values with the same name. Create function does > not return an error. But the invocation at the run time returns a perplexing > 4457 error indicating internal out-of-range index error. > (b) myudf2 defines an input value and an output value with the same name. > Create function does not return an error. But the invocation at the run time > returns a perplexing 4457 error complaining that there is no output value. > (c) myudf3 defines 2 output values with the same name. Create function does > not return an error. The invocation at the run time simply ignores the 2nd > output value, as well as the fact that the C function only defines 1 output > value. It returns one value as if the 2nd output value was never defined at > all. > This is seen on the v0407 build installed on a workstation. To reproduce it: > (1) Download the attached tar file and untar it to get the 3 files in there. > Put the files in any directory . > (2) Make sure that you have run ./sqenv.sh of your Trafodion instance first > as building UDF needs $MY_SQROOT for the header files. > (3) run build.sh > (4) Change the line “create library qa_udf_lib file '/myudf.so';”; in > mytest.sql and fill in > (5) From sqlci, obey mytest.sql > > Here is the execution output: > >>create schema mytest; > --- SQL operation complete. > >>set schema mytest; > --- SQL operation complete. > >> > >>create library qa_udf_lib file '/myudf.so'; > --- SQL operation complete. > >> > >>create table mytable (a int, b int); > --- SQL operation complete. > >>insert into mytable values (1,1),(2,2),(3,3); > --- 3 row(s) inserted. > >> > >>create function myudf1 > +>(INVAL int, INVAL int) > +>returns (OUTVAL int) > +>language c > +>parameter style sql > +>external name 'qa_func_int32' > +>library qa_udf_lib > +>deterministic > +>state area size 1024 > +>allow any parallelism > +>no sql; > --- SQL operation complete. > >> > >>select myudf1(a, b) from mytable; > *** ERROR[4457] An error was encountered processing metadata for user-defined > function TRAFODION.MYTEST.MYUDF1. Details: Internal error in > setInOrOutParam(): index position out of range.. > *** ERROR[8822] The statement was not prepared. > >> > >>create function myudf2 > +>(INVAL int) > +>returns (INVAL int) > +>language c > +>parameter style sql > +>external name 'qa_func_int32' > +>library qa_udf_lib > +>deterministic > +>state area size 1024 > +>allow any parallelism > +>no sql; > --- SQL operation complete. > >> > >>select myudf2(a) from mytable; > *** ERROR[4457] An error was encountered processing metadata for user-defined > function TRAFODION.MYTEST.MYUDF2. Details: User-defined functions must have > at least one registered output value. > *** ERROR[8822] The statement was not prepared. > >> > >>create function myudf3 > +>(INVAL int) > +>returns (OUTVAL int, OUTVAL int) > +>language c > +>parameter style sql > +>external name 'qa_func_int32' > +>library qa_udf_lib > +>deterministic > +>state area size 1024 > +>allow any parallelism > +>no sql; > --- SQL operation complete. > >> > >>select myudf3(a) from mytable; > OUTVAL > --- > 1 > 2 > 3 > --- 3 row(s) selected. > >> > >>drop function myudf1 cascade; > --- SQL operation complete. > >>drop function myudf2 cascade; > --- SQL operation complete. > >>drop function myudf3 cascade; > --- SQL operation complete. > >>drop library qa_udf_lib cascade; > --- SQL operation complete. > >>drop schema mytest cascade; > --- SQL operation complete. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3166) 8427 error string missing when thrown by sequence operator
[ https://issues.apache.org/jira/browse/TRAFODION-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3166: - Fix Version/s: (was: 2.3) 2.4 > 8427 error string missing when thrown by sequence operator > -- > > Key: TRAFODION-3166 > URL: https://issues.apache.org/jira/browse/TRAFODION-3166 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Prashanth Vasudev >Assignee: Prashanth Vasudev >Priority: Major > Fix For: 2.4 > > > *** ERROR[8427] [2018-07-23 15:52:16] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2462) TRAFCI gui installer does not work
[ https://issues.apache.org/jira/browse/TRAFODION-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2462: - Fix Version/s: (was: 2.3) 2.4 > TRAFCI gui installer does not work > -- > > Key: TRAFODION-2462 > URL: https://issues.apache.org/jira/browse/TRAFODION-2462 > Project: Apache Trafodion > Issue Type: Bug > Components: client-ci >Affects Versions: 2.1-incubating >Reporter: Anuradha Hegde >Assignee: Alex Peng >Priority: Major > Fix For: 2.4 > > > There are several issues with trafci > 1. GUI installer on Windows does not work. Bascially the browse button to > upload the T4 jar file and to specify the location of trafci install dir does > not function. hence installation does not proceed > 2. After a successful install of trafci on Windows or *nix we notice that > lib file contains jdbcT4 and jline jar files.. There is no need to > pre-package these files with the product > 3. Running any sql statements from TRAF_HOME folder returns the following > error > SQL>get tables; > *** ERROR[1394] *** ERROR[16001] No message found for SQLCODE -1394. > MXID11292972123518900177319330906U300_877_SQL_CUR_2 > [2017-01-25 20:44:03] > But executing the same statement when you are in $TRAF_HOME/sql/scripts > folder works. > 4. Executing the wrapper script 'trafci' returns and message as below and > proceeds with successful connection. You don't see this messagewhen executing > trafci.sh > /core/sqf/sql/local_hadoop/dcs-2.1.0/bin/dcs-config.sh: line > 90: .: sqenv.sh: file not found > 5. Executing sql statements in multiples lines causes additional SQL prompt > to be displayed > Connected to Apache Trafodion > SQL>get tables > +>SQL> > 6. on successful connect and disconnect when new mxosrvrs are picked up the > default schema is changed from 'SEABASE' to 'USR' (This might be a server > side issue too but will need to debug and find out) > 7. FC command does not work. Look at trafci manual for examples on how FC > command was displayed back, It was shown back with the SQL prompt > SQL>fc > show remoteprocess; > SQL> i > show re moteprocess; > SQL> > 8. Did the error message format change? This should have been syntax error > > SQL>gett; > *** ERROR[15001] *** ERROR[16001] No message found for SQLCODE -15001. > gett; >^ (4 characters from start of SQL statement) > MXID11086222123521382568755030206U300_493_SQL_CUR_4 > [2017-01-25 21:14:18] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2899) Catalog API SQLColumns does not support ODBC2.x
[ https://issues.apache.org/jira/browse/TRAFODION-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2899: - Fix Version/s: (was: 2.3) 2.4 > Catalog API SQLColumns does not support ODBC2.x > --- > > Key: TRAFODION-2899 > URL: https://issues.apache.org/jira/browse/TRAFODION-2899 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Affects Versions: any > Environment: Centos 6.7 >Reporter: XuWeixin >Assignee: XuWeixin >Priority: Major > Fix For: 2.4 > > > When using ODBC2.x to get description of columns, failure occurs but no error > returns. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2917) Refactor Trafodion implementation of hdfs scan for text formatted hive tables
[ https://issues.apache.org/jira/browse/TRAFODION-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2917: - Fix Version/s: (was: 2.3) 2.4 > Refactor Trafodion implementation of hdfs scan for text formatted hive tables > - > > Key: TRAFODION-2917 > URL: https://issues.apache.org/jira/browse/TRAFODION-2917 > Project: Apache Trafodion > Issue Type: New Feature > Components: sql-general >Reporter: Selvaganesan Govindarajan >Priority: Major > Fix For: 2.4 > > > Find below the general outline of hdfs scan for text formatted hive tables. > Compiler returns a list of scan ranges and the begin range and number of > ranges to be done by each instance of TCB in TDB. This list of scan ranges is > also re-computed at run time possibly based on a CQD > The scan range for a TCB can come from the same or different hdfs files. TCB > creates two threads to read these ranges.Two ranges (for the TCB) are > initially assigned to these threads. As and when a range is completed, the > next range (assigned for the TCB) is picked up by the thread. Ranges are read > in multiples of hdfs scan buffer size at the TCB level. Default hdfs scan > buffer size is 64 MB. Rows from hdfs scan buffer is processed and moved into > up queue. If the range contains a record split, then the range is extended to > read up to range tail IO size to get the full row. The range that had the > latter part of the row ignores it because the former range processes it. > Record split at the file level is not possible and/or not supported. > For compression, the compiler returns the range info such that the hdfs scan > buffer can hold the full uncompressed buffer. > Cons: > Reader threads feature too complex to maintain in C++ > Error handling at the layer below the TCB is missing or errors are not > propagated to work method causing incorrect results > Possible multiple copying of data > Libhdfs calls are not optimized. It was observed that the method Ids are > being obtained many times. Need to check if this problem still exists. > Now that we clearly know what is expected, it could be optimized better > - Reduced scan buffer size for smoother data flow > - Better thread utilization > - Avoid multiple copying of data. > Unable to comprehend the need for two threads for pre-fetch especially when > one range is completed fully before the data from next range is processed. > Following are the hdfsCalls used by programs at exp and executor directory. > U hdfsCloseFile > U hdfsConnect > U hdfsDelete > U hdfsExists > U hdfsFlush > U hdfsFreeFileInfo > U hdfsGetPathInfo > U hdfsListDirectory > U hdfsOpenFile > U hdfsPread > U hdfsRename > U hdfsWrite > U hdfsCreateDirectory > New implementation > Make changes to use direct Java APIs for these calls. However, come up with > better mechanism to move the data from Java and JNI, avoid unnecessary > copying of data, better thread management via Executor concepts in Java. > Hence it won’t be direct mapping of these calls to hdfs Java API. Instead, > use the abstraction like what is being done for HBase access. > I believe newer implementation will be optimized better and hence improved > performance. (but not many folds) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2650) The SQLite Trafodion Configuration database storage method can become stale.
[ https://issues.apache.org/jira/browse/TRAFODION-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2650: - Fix Version/s: (was: 2.3) 2.4 > The SQLite Trafodion Configuration database storage method can become stale. > > > Key: TRAFODION-2650 > URL: https://issues.apache.org/jira/browse/TRAFODION-2650 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Affects Versions: 2.2.0 >Reporter: Zalo Correa >Assignee: Zalo Correa >Priority: Major > Fix For: 2.4 > > > The SQLite storage method can prevent a node from initializing properly. This > is due to the nature of SQLIte, a database in a file. The file is updated > locally on each node. In certain failure scenarios, such as Cloudera Manager > and potentially Ambari installations, the file will not be updated locally. > This happens when the monitor process is not running and changes are made to > the configuration, the file in the node where the monitor process is not > executing will become stale and on a node up event, may contain old > configuration information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1628) Implement T2 Driver's Rowsets ability to enhance the batch insert performance
[ https://issues.apache.org/jira/browse/TRAFODION-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1628: - Fix Version/s: (was: 2.3) 2.4 > Implement T2 Driver's Rowsets ability to enhance the batch insert performance > - > > Key: TRAFODION-1628 > URL: https://issues.apache.org/jira/browse/TRAFODION-1628 > Project: Apache Trafodion > Issue Type: Improvement > Components: client-jdbc-t2 >Reporter: RuoYu Zuo >Assignee: RuoYu Zuo >Priority: Critical > Labels: features, performance > Fix For: 2.4 > > > JDBC T2 Driver now has very poor performance of batch insert, because it does > not have rowsets ability. Implement rowsets functionality will allow T2 > Driver performs batch insert operation much faster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2922) calling int[] executeBatch() method execute create/drop/delete/insert/update/upsert statement always return -2
[ https://issues.apache.org/jira/browse/TRAFODION-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2922: - Fix Version/s: (was: 2.3) 2.4 > calling int[] executeBatch() method execute > create/drop/delete/insert/update/upsert statement always return -2 > -- > > Key: TRAFODION-2922 > URL: https://issues.apache.org/jira/browse/TRAFODION-2922 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.3 >Reporter: LiZe >Priority: Major > Fix For: 2.4 > > > calling int[] executeBatch() method execute > create/drop/delete/insert/update/upsert statement always return -2,but jdbc > t2 is pass -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2987) Add documentation of systimestamp and sysdate in sql manual
[ https://issues.apache.org/jira/browse/TRAFODION-2987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2987: - Fix Version/s: (was: 2.3) 2.4 > Add documentation of systimestamp and sysdate in sql manual > --- > > Key: TRAFODION-2987 > URL: https://issues.apache.org/jira/browse/TRAFODION-2987 > Project: Apache Trafodion > Issue Type: Documentation > Components: website >Affects Versions: 2.2.0 >Reporter: Yuan Liu >Assignee: Liu Yu >Priority: Major > Fix For: 2.4 > > > We support both systimestamp and sysdate but they are no documented there. > Systimestamp is equal to current_timestamp, and sysdate is equal to > current_date. > > >>select systimestamp from dual; > > (EXPR) > -- > > 2018-03-10 10:32:19.232949 > > --- 1 row(s) selected. > >>select sysdate from dual; > > (EXPR) > -- > > 2018-03-10 > > --- 1 row(s) selected. > >>select current_timestamp from dual; > > (EXPR) > -- > > 2018-03-10 10:32:30.733581 > > --- 1 row(s) selected. > >>select current_date from dual; > > (EXPR) > -- > > 2018-03-10 > > --- 1 row(s) selected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2963) Remove the 64K hard limit for process ids in RMS infrastructure
[ https://issues.apache.org/jira/browse/TRAFODION-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2963: - Fix Version/s: (was: 2.3) 2.4 > Remove the 64K hard limit for process ids in RMS infrastructure > > > Key: TRAFODION-2963 > URL: https://issues.apache.org/jira/browse/TRAFODION-2963 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > Fix For: 2.4 > > > RMS infrastructure in Trafodion restricts the process ids to a maximum of > 64K. If the cluster is configured with more than 64K process ids, then > Trafodion will not come up. If the installer circumvents the restriction, > then RMS infrastructure would bring down the node due to corruption in the > RMS shared segment. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-480) LP Bug: 1349644 - Status array returned by batch operations contains wrong return value for T2
[ https://issues.apache.org/jira/browse/TRAFODION-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-480: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1349644 - Status array returned by batch operations contains wrong > return value for T2 > -- > > Key: TRAFODION-480 > URL: https://issues.apache.org/jira/browse/TRAFODION-480 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t2, client-jdbc-t4 >Reporter: Aruna Sadashiva >Assignee: RuoYu Zuo >Priority: Major > Fix For: 2.4 > > > The status array returned from T2 contains a different value compared to T4. > T4 returns -2 and T2 returns 1. > The oracle JDBC documentation states: > 0 or greater — the command was processed successfully and the value is an > update count indicating the number of rows in the database that were affected > by the command’s execution Chapter 14 Batch Updates 121 > Statement.SUCCESS_NO_INFO — the command was processed successfully, but the > number of rows affected is unknown > Statement.SUCCESS_NO_INFO is defined as being -2, so your result says > everything worked fine, but you won't get information on the number of > updated columns. > For a prepared statement batch, it is not possible to know the number of rows > affected in the database by each individual statement in the batch. > Therefore, all array elements have a value of -2. According to the JDBC 2.0 > specification, a value of -2 indicates that the operation was successful but > the number of rows affected is unknown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2660) elastic - sqcheck cannot display configured TM/RMS count when instance is down
[ https://issues.apache.org/jira/browse/TRAFODION-2660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2660: - Fix Version/s: (was: 2.3) 2.4 > elastic - sqcheck cannot display configured TM/RMS count when instance is down > -- > > Key: TRAFODION-2660 > URL: https://issues.apache.org/jira/browse/TRAFODION-2660 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Reporter: Yi (Eason) Zhang >Assignee: Zalo Correa >Priority: Major > Fix For: 2.4 > > > With the latest elastic changes, now if instance is up, sqcheck works well, > but if instance is down, sqcheck cannot display the correct configured TM/RMS > count: > [trafodion@eason-1 scripts]$ sqcheck > > *** Checking Trafodion Environment *** > > Checking if processes are up. > Checking attempt: 1; user specified max: 2. Execution time in seconds: 4. > > The Trafodion environment is not up at all, or partially up and not > operational. Check the logs. > > Process Configured Actual Down > --- -- -- > DTM 0 0 > RMS 0 0 > DcsMaster 1 0 1 > DcsServer 2 0 2 > mxosrvr 8 0 8 > RestServer 0 0 > > > The Trafodion environment is down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2884) Trafodion Foundation Scalability Enhancements
[ https://issues.apache.org/jira/browse/TRAFODION-2884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2884: - Fix Version/s: (was: 2.3) 2.4 > Trafodion Foundation Scalability Enhancements > - > > Key: TRAFODION-2884 > URL: https://issues.apache.org/jira/browse/TRAFODION-2884 > Project: Apache Trafodion > Issue Type: Improvement > Components: dtm, foundation, installer >Affects Versions: 2.3 >Reporter: Zalo Correa >Assignee: Zalo Correa >Priority: Major > Fix For: 2.4 > > Attachments: > TRAFODION-2884-Scalable_Name_Space-Architecure-review.v2.2.pdf, > TRAFODION-2884-Scalable_Name_Space-Architecure.v1.0.pdf, > TRAFODION-2884-Scalable_Name_Space-Architecure.v1.1.pdf, > TRAFODION-2884-Scalable_Name_Space-Architecure.v2.0.pdf, > TRAFODION-2884-Scalable_Name_Space-Architecure.v2.1.pdf, > TRAFODION-2884-Scalable_Name_Space-Architecure.v2.2.pdf, > TRAFODION-2884-Scalable_Name_Space-DesignNotes-review.v1.0.pdf, > TRAFODION-2884-Scalable_Name_Space-DesignNotes.v0.1.pdf, > TRAFODION-2884-Scalable_Name_Space-DesignNotes.v1.0.pdf, > TRAFODION-2884-Scalable_Name_Space-Overview-20180308.pptx > > > Architectural changes are needed in the Trafodion Foundation components to > effectively scale above 256 servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2995) https links in code
[ https://issues.apache.org/jira/browse/TRAFODION-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2995: - Fix Version/s: (was: 2.3) 2.4 > https links in code > --- > > Key: TRAFODION-2995 > URL: https://issues.apache.org/jira/browse/TRAFODION-2995 > Project: Apache Trafodion > Issue Type: Sub-task >Reporter: Pierre Smits >Assignee: Pierre Smits >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2882) Foundation infrastructure changes needed to support operating in Cloudera Manager environment
[ https://issues.apache.org/jira/browse/TRAFODION-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2882: - Fix Version/s: (was: 2.3) 2.4 > Foundation infrastructure changes needed to support operating in Cloudera > Manager environment > - > > Key: TRAFODION-2882 > URL: https://issues.apache.org/jira/browse/TRAFODION-2882 > Project: Apache Trafodion > Issue Type: Improvement > Components: foundation >Affects Versions: 2.3 >Reporter: Zalo Correa >Assignee: Zalo Correa >Priority: Major > Fix For: 2.4 > > > The method for starting a Trafodion instance is based on Open MPI. A > different method is needed to remove this dependency and to allow for larger > cluster configuration installations. > This calls for a different method of instantiating a Trafodion cluster > instance which utilizes existing node reintegration, i.e., node up, > capability and is not dependent on Open MPI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-206) LP Bug: 1297518 - DCS - SQLProcedures and SQLProcedureColumns need to be supported
[ https://issues.apache.org/jira/browse/TRAFODION-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-206: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1297518 - DCS - SQLProcedures and SQLProcedureColumns need to be > supported > -- > > Key: TRAFODION-206 > URL: https://issues.apache.org/jira/browse/TRAFODION-206 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-general >Reporter: Aruna Sadashiva >Assignee: Kevin Xu >Priority: Critical > Fix For: 2.4 > > > DCS needs to implement support for SQLProcedures and SQLProcedureColumns, > since traf sql supports SPJs now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1258) LP Bug: 1461209 - SPJ with resultset doesnt work thru T2 driver
[ https://issues.apache.org/jira/browse/TRAFODION-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1258: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1461209 - SPJ with resultset doesnt work thru T2 driver > --- > > Key: TRAFODION-1258 > URL: https://issues.apache.org/jira/browse/TRAFODION-1258 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t2 >Reporter: Aruna Sadashiva >Assignee: Weiqing Xu >Priority: Critical > Fix For: 2.4 > > > SPJ with resultsets work ok thru T4 driver, but fails when invoked thru T2 > driver. There is no diagnostics of any sort. > This seems to be equivalent of invoking an spj with resultset from another > spj in T4. There is a bug for that : > https://bugs.launchpad.net/trafodion/+bug/1355042 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2664) Instance will be down when the zookeeper on name node has been down
[ https://issues.apache.org/jira/browse/TRAFODION-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2664: - Fix Version/s: (was: 2.3) 2.4 > Instance will be down when the zookeeper on name node has been down > --- > > Key: TRAFODION-2664 > URL: https://issues.apache.org/jira/browse/TRAFODION-2664 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Affects Versions: 2.2.0 > Environment: Test Environment: > CDH5.4.8: 10.10.23.19:7180, total 6 nodes. > HDFS-HA and DCS-HA: enabled > OS: Centos6.8, physic machine. > SW Build: R2.2.3 (EsgynDB_Enterprise Release 2.2.3 (Build release [sbroeder], > branch 1ce8d39-xdc_nari, date 11Jun17) >Reporter: Jarek >Assignee: Zalo Correa >Priority: Critical > Labels: build > Fix For: 2.4 > > > Description: Instance will be down when the zookeeper on name node has been > down > Test Steps: > Step 1. Start OE and 4 long queries with trafci on the first node > esggy-clu-n010 > Step 2. Wait several minutes and stop zookeeper on name node of node > esggy-clu-n010 in Cloudera Manager page. > Step 3. With trafci, run a basic query and 4 long queries again. > In the above Step 3, we will see the whole instance as down after a while. > For this test scenario, I tried it several times, always found instance as > down. > Timestamp: > Test Start Time: 20170616132939 > Test End Time: 20170616134350 > Stop zookeeper on name node of node esggy-clu-n010: 20170616133344 > Check logs: > 1) Each node displays the following error: > 2017-06-16 13:33:46,276, ERROR, MON, Node Number: 0,, PIN: 5017 , Process > Name: $MONITOR,,, TID: 5429, Message ID: 101371801, > [CZClient::IsZNodeExpired], zoo_exists() for > /trafodion/instance/cluster/esggy-clu-n010.esgyn.cn failed with error > ZCONNECTIONLOSS > 2) Zookeeper displays: > ls /trafodion/instance/cluster > [] > So, It seems zclient has been lost on each node. > Location of logs: > esggy-clu-n010: > /data4/jarek/ha.interactive/trafodion_and_cluster_logs/cluster_logs.20170616134816.tar.gz > and trafodion_logs.20170616134816.tar.gz > By the way, because the size of the logs is out of the limited value, so i > cannot upload it as the attachment in this JIRA ID. > How many zookeeper quorum servers in the cluster? total 3. > > dcs.zookeeper.quorum > > esggy-clu-n010.esgyn.cn,esggy-clu-n011.esgyn.cn,esggy-clu-n012.esgyn.cn > > How to access the cluster? > 1. Login 10.10.10.8 from US machine: trafodion/traf123 > 2. Login 10.10.23.19 from 10.10.10.8: trafodion/traf123 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1117) LP Bug: 1438961 - ODB doesn't terminate connections with DB when execution is interrupted
[ https://issues.apache.org/jira/browse/TRAFODION-1117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1117: - Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1438961 - ODB doesn't terminate connections with DB when execution is > interrupted > - > > Key: TRAFODION-1117 > URL: https://issues.apache.org/jira/browse/TRAFODION-1117 > Project: Apache Trafodion > Issue Type: Bug > Components: db-utility-odb >Reporter: Weiqing Xu >Assignee: Weiqing Xu >Priority: Blocker > Fix For: 2.4 > > > If execution of ODB is interrupted then it does not terminate connections > with DB (Trafodion) . > Restarting DCS does not help. It shows odb app is still occupying MXOSRVRs. > Also, re-executing odb throws following error message: > - > odb [2015-03-31 21:19:11]: starting ODBC connection(s)... (1) 1 2 3 4 > Connected to HP Database > [3] 5,000 records inserted [commit] > [2] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [2] 0 records inserted [commit] > [3] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [3] 5,000 records inserted [commit] > [4] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [4] 0 records inserted [commit] > [1] odb [Oloadbuff(9477)] - Error (State: 25000, Native -8606) > [Trafodion ODBC Driver][Trafodion Database] SQL ERROR:*** ERROR[8606] > Transaction subsystem TMF returned error 97 on a commit transaction. > [2015-03-31 21:39:47] > [1] 0 records inserted [commit] > odb [sigcatch(4125)] - Received SIGINT. Exiting > - > ODB version: odb64luo > Trafodion Build: Release [1.0.0-304-ga977ee7_Bld14], branch a977ee7-master, > date 20150329_083001) > Hadoop Distro: HDP 2.2 > HBase Version: 0.98.4.2.2.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1186) LP Bug: 1445310 - sqgen may NOT copy all script files to all nodes
[
https://issues.apache.org/jira/browse/TRAFODION-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-1186:
-
Fix Version/s: (was: 2.3)
2.4
> LP Bug: 1445310 - sqgen may NOT copy all script files to all nodes
> --
>
> Key: TRAFODION-1186
> URL: https://issues.apache.org/jira/browse/TRAFODION-1186
> Project: Apache Trafodion
> Issue Type: Bug
> Components: foundation
>Reporter: Guy Groulx
>Assignee: Zalo Correa
>Priority: Major
> Fix For: 2.4
>
>
> I expanded a system from 2 nodes to 4 nodes.
> After modifying sqconfig, I ran sqgen.
> 1- the pdcp command
> $SQ_PDCP -p -w ${ExNodeList[@]} -x `uname -n` sqconfig sqshell
> gomon.cold gomon.warm shell.env mon.env $PWD
> failed since shell.env and mon.end do not exist on the source node.
> 2- the files sscpstart sscpstop ssmpstart and ssmpstop were regenerated but
> not copied to all the nodes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-3279) get lob stats fail when mixing lob and normal columns
[
https://issues.apache.org/jira/browse/TRAFODION-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-3279:
-
Fix Version/s: (was: 2.3)
2.4
> get lob stats fail when mixing lob and normal columns
> -
>
> Key: TRAFODION-3279
> URL: https://issues.apache.org/jira/browse/TRAFODION-3279
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Affects Versions: any
>Reporter: He Zhenxing
>Priority: Minor
> Fix For: 2.4
>
>
> When mixing lob and normal columns like this:
> {noformat}
> >> cqd traf_blob_as_varchar 'off';
> >> create table t1 (a int, b blob);
> >> create table t2 (a blob, b int, c blob);
> {noformat}
> try get lob stats will fail with this error:
> {noformat}
> >> get lob stats for table t1
> *** ERROR[4082] Object
> TRAFODION.SCH."LOBDescChunks__02697841542402152109_0001" does not exist or is
> inaccessible.
> *** ERROR[8822] The statement was not prepared.
> --- SQL operation failed with errors.
> >> get lob stats for table t2
> *** ERROR[4082] Object
> TRAFODION.SCH."LOBDescChunks__02697841542402158348_0002" does not exist or is
> inaccessible.
> *** ERROR[8822] The statement was not prepared.
> --- SQL operation failed with errors.
> {noformat}
> It seems it will wrongly used the lob number as the lob column number.
> Please note that showddl , lob detail command is not affected, but
> select * from table(lob stats()) suffer the same problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-2830) odb export will scan full table with splitby column
[
https://issues.apache.org/jira/browse/TRAFODION-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-2830:
-
Fix Version/s: (was: 2.3)
2.4
> odb export will scan full table with splitby column
> ---
>
> Key: TRAFODION-2830
> URL: https://issues.apache.org/jira/browse/TRAFODION-2830
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: db-utility-odb
>Affects Versions: 2.1-incubating
>Reporter: 苏锦佩
>Assignee: 苏锦佩
>Priority: Major
> Fix For: 2.4
>
>
> use odb to extract data parallel with splitby column, when get min/max value
> from table, it will missing pwhere condition.
> step to reproduce:
> {code:java}
> odb64luo -u db__root -p xx -d traf -e "src=cdr:pwhere=[service_id >
> 100]:tgt=cdr.txt:parallel=4:splitby=service_id",
> {code}
> we can got the query to get min/max service_id,it is full table scan, the
> query missing the [service_id > 100] condition.
> {code:java}
> [trafodion@esggy-poc-n012 ~]$ offender -s active
> EsgynDB Advanced Conversational Interface 2.3.0
> Copyright (c) 2015-2017 Esgyn Corporation
> >>+>+>+>+>+>+>+>+>+>+>+>+>+>
> CURRENT_TIMESTAMP LAST_ACTIVITY_SECS QUERY_ID EXECUTE_STATE SOURCE_TEXT
> --
>
> 2017-12-05 11:58:34.230648 18
> MXID110030447252123791175981272260206U308T15000_32_SQL_CUR_13
> OPEN "SELECT MIN(SERVICE_ID), MAX(SERVICE_ID) FROM CDR
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-2903) The COLUMN_SIZE fetched from mxosrvr is wrong
[ https://issues.apache.org/jira/browse/TRAFODION-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2903: - Fix Version/s: (was: 2.3) 2.4 > The COLUMN_SIZE fetched from mxosrvr is wrong > - > > Key: TRAFODION-2903 > URL: https://issues.apache.org/jira/browse/TRAFODION-2903 > Project: Apache Trafodion > Issue Type: Bug > Components: connectivity-mxosrvr >Affects Versions: any >Reporter: XuWeixin >Assignee: XuWeixin >Priority: Major > Fix For: 2.4 > > > 1. DDL: create table TEST (C1 L4PKE date,C2 time,C3 timestamp) > 2. > SQLColumns(hstmt,(SQLTCHAR*)"TRAFODION",SQL_NTS,(SQLTCHAR*)"SEABASE",SQL_NTS,(SQLTCHAR*)"TEST",SQL_NTS,(SQLTCHAR*)"%",SQL_NTS); > 3. SQLBindCol(hstmt,7,SQL_C_LONG,,0,) > 4. SQLFetch(hstmt) > return DATE ColPrec expect: 10 and actual: 11 >TIME ColPrec expect: 8 and actual: 9 >TIMESTAMP ColPrec expect: 19 and actual: 20 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2870) DCS can not be normal visit.
[ https://issues.apache.org/jira/browse/TRAFODION-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2870: - Fix Version/s: (was: 2.3) 2.4 > DCS can not be normal visit. > > > Key: TRAFODION-2870 > URL: https://issues.apache.org/jira/browse/TRAFODION-2870 > Project: Apache Trafodion > Issue Type: Bug > Components: client-jdbc-t4 >Affects Versions: 2.3 > Environment: vmware+centos 6.5 >Reporter: surgingcode >Priority: Major > Fix For: 2.4 > > > After deploying a standalone version of trafodion. > Java normal use jdbcT4.jar connect to the database and found that the client > can not connect to the DCS service. > But the server trafci can be used normally. > so,I found that because the host default name is localhost. > Not feeling reasonable, stand-alone version does not modify the host name, > but also commonly used things. > This problem occurs, suggesting that the certificate can not be downloaded > normally, even if the server name should not be configured localhost, it > should not prompt network error, because the core of this problem is the > client and server can not be properly resolved to the correct server address > (internet Address / intranet address / loop address). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1958) sqps and sqcheck display wrong information after node reintegrated
[ https://issues.apache.org/jira/browse/TRAFODION-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1958: - Fix Version/s: (was: 2.3) 2.4 > sqps and sqcheck display wrong information after node reintegrated > -- > > Key: TRAFODION-1958 > URL: https://issues.apache.org/jira/browse/TRAFODION-1958 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Affects Versions: 2.0-incubating > Environment: all >Reporter: Zalo Correa >Assignee: Zalo Correa >Priority: Minor > Labels: CI, test > Fix For: 2.4 > > Original Estimate: 72h > Remaining Estimate: 72h > > Looks like after a node failure/reintegration, we see this confusing behavior: > > Processes with a ‘named’ parent process ‘may’ have incorrect info. When I did > an sqps on ctsha-2, see these processes on nid 3 without the program file > name (running sqps on nid 2, 3 or 4 gives the correct program name, which is > ‘tdm_arkcmp’): > [$Z0019TI] 003,00012563 001 GEN ES--A-- $Z030A8Y $Z0316UD > [$Z0019TI] 003,00033477 001 GEN ES--A-- $Z030SBH $Z03171T > [$Z0019TI] 003,00033776 001 GEN ES--A-- $Z030SK1 $Z030SBH > > Local monitor has correct info about processes on its own node -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-138) LP Bug: 1246183 - volatile table is not dropped after hpdci session ends
[ https://issues.apache.org/jira/browse/TRAFODION-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-138: Fix Version/s: (was: 2.3) 2.4 > LP Bug: 1246183 - volatile table is not dropped after hpdci session ends > > > Key: TRAFODION-138 > URL: https://issues.apache.org/jira/browse/TRAFODION-138 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Weishiun Tsai >Assignee: Sandhya Sundaresan >Priority: Critical > Fix For: 2.4 > > > A volatile table is not dropped after the hpdci session has ended. In the > following example, the volatile table persists after several hpdci > disconnects and reconnects. This problem is not seen from sqlci, so I am > assuming that the problem is in how mxosvr handles volatile tables. > -bash-4.1$ hpdci.seascape2-sqtopl7.sh > Welcome to HP Database Command Interface 3.0 > (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP. > Connected to Data Source: TDM_Default_DataSource > SQL>set schema seabase.mytest; > --- SQL operation complete. > SQL>create volatile table abc (a int not null not droppable primary key); > --- SQL operation complete. > SQL>showddl abc; > CREATE VOLATILE TABLE ABC > ( > AINT NO DEFAULT NOT NULL NOT DROPPABLE > , PRIMARY KEY (A ASC) > ) > ; > --- SQL operation complete. > SQL>exit; > -bash-4.1$ hpdci.seascape2-sqtopl7.sh > Welcome to HP Database Command Interface 3.0 > (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP. > Connected to Data Source: TDM_Default_DataSource > SQL>set schema seabase.mytest; > --- SQL operation complete. > SQL>showddl abc; > CREATE VOLATILE TABLE ABC > ( > AINT NO DEFAULT NOT NULL NOT DROPPABLE > , PRIMARY KEY (A ASC) > ) > ; > --- SQL operation complete. > SQL>exit; > -bash-4.1$ hpdci.seascape2-sqtopl7.sh > Welcome to HP Database Command Interface 3.0 > (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP. > Connected to Data Source: TDM_Default_DataSource > SQL>set schema seabase.mytest; > --- SQL operation complete. > SQL>showddl abc; > CREATE VOLATILE TABLE ABC > ( > AINT NO DEFAULT NOT NULL NOT DROPPABLE > , PRIMARY KEY (A ASC) > ) > ; > --- SQL operation complete. > SQL>exit; > -bash-4.1$ hpdci.seascape2-sqtopl7.sh > Welcome to HP Database Command Interface 3.0 > (c) Copyright 2010-2012 Hewlett-Packard Development Company, LP. > Connected to Data Source: TDM_Default_DataSource > SQL>set schema seabase.mytest; > --- SQL operation complete. > SQL>showddl abc; > CREATE VOLATILE TABLE ABC > ( > AINT NO DEFAULT NOT NULL NOT DROPPABLE > , PRIMARY KEY (A ASC) > ) > ; > --- SQL operation complete. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1803) Range delete on tables with nullable key columns deletes fewer rows
[ https://issues.apache.org/jira/browse/TRAFODION-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-1803: - Fix Version/s: (was: 2.3) 2.4 > Range delete on tables with nullable key columns deletes fewer rows > > > Key: TRAFODION-1803 > URL: https://issues.apache.org/jira/browse/TRAFODION-1803 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Affects Versions: 1.2-incubating >Reporter: Suresh Subbiah >Assignee: Suresh Subbiah >Priority: Major > Fix For: 2.4 > > > When a table has nullable columns in the primary/store by key and these > columns have null values, delete and update statements may affect fewer rows > than intended. > For example > >>cqd allow_nullable_unique_key_constraint 'on' ; > --- SQL operation complete. > CREATE TABLE TRAFODION.JIRA.T1 > ( > AINT DEFAULT NULL SERIALIZED > , BINT DEFAULT NULL SERIALIZED > , PRIMARY KEY (A ASC, B ASC) > ) > ; > --- SQL operation complete. > >>insert into t1 values (1, null) ; > --- 1 row(s) inserted. > >>delete from t1 where a = 1 ; > --- 0 row(s) deleted. > >>delete from t1 ; > --- 0 row(s) deleted. > >>delete from t1 where a =1 and b is null ; > --- 1 row(s) deleted. > >>explain delete from t1 where a =1 ; > TRAFODION_DELETE == SEQ_NO 2NO CHILDREN > TABLE_NAME ... TRAFODION.JIRA.T1 > REQUESTS_IN . 10 > ROWS/REQUEST . 1 > EST_OPER_COST 0.17 > EST_TOTAL_COST ... 0.17 > DESCRIPTION > max_card_est .. 99 > fragment_id 0 > parent_frag (none) > fragment_type .. master > iud_type ... trafodion_delete TRAFODION.JIRA.T1 > predicate .. (A = %(1)) and (B = B) > begin_key .. (A = %(1)) and (B = B) > end_key (A = %(1)) and (B = B) > Similar issue can be seen for update statements too > > >>CREATE TABLE TRAFODION.JIRA.T2 > ( > AINT DEFAULT NULL SERIALIZED > , BINT DEFAULT NULL SERIALIZED > , CINT DEFAULT NULL SERIALIZED > , PRIMARY KEY (A ASC, B ASC) > ) > ;+>+>+>+>+>+>+> > --- SQL operation complete. > >> > >> > >>insert into t2 values (1, null, 3) ; > --- 1 row(s) inserted. > >>update t2 set c = 30 where a = 1 ; > --- 0 row(s) updated. > > TRAFODION_UPDATE == SEQ_NO 2NO CHILDREN > TABLE_NAME ... TRAFODION.JIRA.T2 > REQUESTS_IN .. 1 > ROWS_OUT . 1 > EST_OPER_COST 0 > EST_TOTAL_COST ... 0 > DESCRIPTION > max_card_est .. 99 > fragment_id 0 > parent_frag (none) > fragment_type .. master > iud_type ... trafodion_update TRAFODION.JIRA.T2 > new_rec_expr ... (C assign %(30)) > predicate .. (A = %(1)) and (B = B) > begin_key .. (A = %(1)) and (B = B) > end_key (A = %(1)) and (B = B) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2741) LOB support in JDBC Type 2
[ https://issues.apache.org/jira/browse/TRAFODION-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2741: - Fix Version/s: (was: 2.3) 2.4 > LOB support in JDBC Type 2 > -- > > Key: TRAFODION-2741 > URL: https://issues.apache.org/jira/browse/TRAFODION-2741 > Project: Apache Trafodion > Issue Type: Sub-task > Components: client-jdbc-t4, connectivity-mxosrvr >Reporter: Weiqing Xu >Assignee: Weiqing Xu >Priority: Major > Fix For: 2.4 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2427) trafodion 2.0.1 install occurs an error ERROR: unable to find hbase-trx-cdh5_5-*.jar5-*.jar
[ https://issues.apache.org/jira/browse/TRAFODION-2427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2427: - Fix Version/s: (was: 2.3) 2.4 > trafodion 2.0.1 install occurs an error ERROR: unable to find > hbase-trx-cdh5_5-*.jar5-*.jar > --- > > Key: TRAFODION-2427 > URL: https://issues.apache.org/jira/browse/TRAFODION-2427 > Project: Apache Trafodion > Issue Type: Question > Components: installer >Reporter: jacklee >Priority: Major > Labels: beginner > Fix For: 2.4 > > > trafodion 2.0.1 install occurs an error > ***INFO: Cloudera installed will run traf_cloudera_mods > ***ERROR: unable to find > /usr/lib/trafodion/apache-trafodion_server-2.0.1-incubating/export/lib/hbase-trx-cdh5_5-*.jar > ***ERROR: traf_cloudera_mods exited with error. > ***ERROR: Please check log files. > ***ERROR: Exiting > help somebody help me,thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-1575) Self-referencing update updates the column to a wrong value
[
https://issues.apache.org/jira/browse/TRAFODION-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Selvaganesan Govindarajan updated TRAFODION-1575:
-
Fix Version/s: (was: 2.3)
2.4
> Self-referencing update updates the column to a wrong value
> ---
>
> Key: TRAFODION-1575
> URL: https://issues.apache.org/jira/browse/TRAFODION-1575
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-cmp
>Affects Versions: 1.3-incubating
> Environment: Can be reproduced on a workstation
>Reporter: Dave Birdsall
>Assignee: Selvaganesan Govindarajan
>Priority: Major
> Fix For: 2.4
>
>
> As shown in the following execution output, the update statement tries to
> update c2 with count(distinct c2) from the same table. While the subquery
> ‘select c from (select count(distinct c2) from mytable) dt(c)’ returns the
> correct result 3 when it is run by itself, the update statement using the
> same subquery updated the column c2 to 2, instead of 3. The updated value
> always seems to be 1 less in this case.
> Here is the execution output:
> >>create schema mytest;
> --- SQL operation complete.
> >>
> >>create table mytable (c1 char(1), c2 integer);
> --- SQL operation complete.
> >>
> >>insert into mytable values ('A', 100), ('B', 200), ('C', 300);
> --- 3 row(s) inserted.
> >>select * from mytable order by 1;
> C1 C2
> -- ---
> A 100
> B 200
> C 300
> --- 3 row(s) selected.
> >>select c from (select count(distinct c2) from mytable) dt(c);
> C
>
>3
> --- 1 row(s) selected.
> >>
> >>prepare xx from update mytable set c2 =
> +>(select c from (select count(distinct c2) from mytable) dt(c))
> +>where c2 = 100;
> --- SQL command prepared.
> >>explain options 'f' xx;
> LC RC OP OPERATOR OPT DESCRIPTION CARD
> -
> 12 . 13 root x 1.00E+001
> 10 11 12 tuple_flow 1.00E+001
> . . 11 trafodion_insert MYTABLE 1.00E+000
> 9 . 10 sort 1.00E+001
> 8 4 9 hybrid_hash_join 1.00E+001
> 6 7 8 nested_join 1.00E+001
> . . 7 trafodion_delete MYTABLE 1.00E+000
> 5 . 6 sort 1.00E+001
> . . 5 trafodion_scan MYTABLE 1.00E+001
> 3 . 4 sort_scalar_aggr 1.00E+000
> 2 . 3 sort_scalar_aggr 1.00E+000
> 1 . 2 hash_groupby 2.00E+000
> . . 1 trafodion_scan MYTABLE 1.00E+002
> --- SQL operation complete.
> >>execute xx;
> --- 1 row(s) updated.
> >>
> >>select * from mytable order by 1;
> C1 C2
> -- ---
> A 2
> B 200
> C 300
> --- 3 row(s) selected.
> >>
> >>drop schema mytest cascade;
> --- SQL operation complete.
> >>
> The value of C2 in row A above should have been updated to 3.
> This problem was found by Wei-Shiun Tsai.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TRAFODION-2940) In HA env, one node lose network, when recover, trafci can't use
[ https://issues.apache.org/jira/browse/TRAFODION-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2940: - Fix Version/s: (was: 2.3) 2.4 > In HA env, one node lose network, when recover, trafci can't use > > > Key: TRAFODION-2940 > URL: https://issues.apache.org/jira/browse/TRAFODION-2940 > Project: Apache Trafodion > Issue Type: Bug >Affects Versions: any >Reporter: mashengchen >Assignee: mashengchen >Priority: Major > Fix For: 2.4 > > > In HA env, if one node lose network for a long time , once network recover, > there will have two floating ip, two working dcs master, and trafci can't be > use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3049) Inaccurate conditions of judgment cause low efficiency
[ https://issues.apache.org/jira/browse/TRAFODION-3049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3049: - Fix Version/s: (was: 2.3) 2.4 > Inaccurate conditions of judgment cause low efficiency > -- > > Key: TRAFODION-3049 > URL: https://issues.apache.org/jira/browse/TRAFODION-3049 > Project: Apache Trafodion > Issue Type: Bug > Components: client-odbc-linux, client-odbc-windows >Affects Versions: any >Reporter: XuWeixin >Assignee: XuWeixin >Priority: Major > Fix For: 2.4 > > > In ctosqlconv.cpp, the code below : > if( !(((SQLDataType == SQLTYPECODE_NUMERIC) && (targetPrecision > 18)) || > ((SQLDataType == SQLTYPECODE_NUMERIC_UNSIGNED) && (targetPrecision > 9 > > Only when the column is NUMERIC(19+,n), the code will skip. > It is only used for numeirc but now the other data type such as char will do > the same process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2308) JDBC T4 support read LOB
[ https://issues.apache.org/jira/browse/TRAFODION-2308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2308: - Fix Version/s: (was: 2.3) 2.4 > JDBC T4 support read LOB > > > Key: TRAFODION-2308 > URL: https://issues.apache.org/jira/browse/TRAFODION-2308 > Project: Apache Trafodion > Issue Type: Sub-task > Components: client-jdbc-t4, connectivity-mxosrvr >Affects Versions: 2.1-incubating >Reporter: Weiqing Xu >Assignee: Weiqing Xu >Priority: Major > Fix For: 2.4 > > > JDBC T4 need implement some API to support CLOB and BLOB. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-2775) Insert does not raise duplicate row error for hbase format table with defaulted first column
[ https://issues.apache.org/jira/browse/TRAFODION-2775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-2775: - Fix Version/s: (was: 2.3) 2.4 > Insert does not raise duplicate row error for hbase format table with > defaulted first column > - > > Key: TRAFODION-2775 > URL: https://issues.apache.org/jira/browse/TRAFODION-2775 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Suresh Subbiah >Assignee: Suresh Subbiah >Priority: Major > Fix For: 2.4 > > > This issue was found by Gunnar Tapper and Carol Pearson. > With HBase format Trafodion tables (each column in a row is a separate Cell), > if the first column in the table can be defaulted, then uniqueness violations > are not raised as expected for INSERT statements. Here is an example > create table def1 (c1 int, c2 int not null, c3 int, primary key (c2)) > attributes hbase format; > insert into def1 (c2) values (1); > -- raises unique constraint error as expected > insert into def1 (c2, c3) values (1,3); > -- does not raise constraint error > insert into def1 (c1, c2) values (1,1); > The problem is that during the checkAndPut for INSERTcall we are specifying > the column to be checked as the one that has index 0 in the row being > inserted. This would the first column being inserted into for the row, as > specified by DDL, once omitted columns are removed. Columns with default > value could be omitted in a given INSERT, if they are not part of the > clustering key. > The fix utilizes that fact that clustering key columns are always present in > the row being inserted, even if they can be defaulted and not explicitly in > the INSERT statement. We now pass in the index of the first clustering key > column, in the row being inserted, to the java layer. The java layer will get > the column name/qualifier from the java byte buffer version of row being > inserted and use it in the CheckAndPut call. Not that the index of first > clustering key column will depend on both which default columns are being > skipped and order of columns in DDL. This index does not depend only on DDL. > With the change we get the expected error > >>insert into def1 (c1, c2) values (1,1); > *** ERROR[8102] The operation is prevented by a unique constraint. > --- 0 row(s) inserted. > >>insert into def1 (c2, c1) values (51,1); > --- 1 row(s) inserted. > >>insert into def1 (c2, c1) values (1,51); > *** ERROR[8102] The operation is prevented by a unique constraint. > --- 0 row(s) inserted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3335) DDL takes a longer time when there are many snapshots
Selvaganesan Govindarajan created TRAFODION-3335: Summary: DDL takes a longer time when there are many snapshots Key: TRAFODION-3335 URL: https://issues.apache.org/jira/browse/TRAFODION-3335 Project: Apache Trafodion Issue Type: Bug Components: sql-general Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan When there are many snapshots the HBaseAdmin.listSnapshots can take considerably long time. There is no method to get the snapshot for a given table name in HBase 1.1. So, it is prudent to avoid using HBaseAdmin.listSnapshots wherever it is possible, -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (TRAFODION-3331) JDBC T4 driver to support login timeout and query timeout
[ https://issues.apache.org/jira/browse/TRAFODION-3331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-3331: Assignee: Selvaganesan Govindarajan > JDBC T4 driver to support login timeout and query timeout > --- > > Key: TRAFODION-3331 > URL: https://issues.apache.org/jira/browse/TRAFODION-3331 > Project: Apache Trafodion > Issue Type: Bug >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > JDBC T4 driver lacks in functionality to support login timeout and query > timeout. In addition the query timeout needs to sync up with cancelling > query functionality in Trafodion SQL engine. It is possible that graceful > query cancel is disabled in the Trafodion SQL engine. In that the process > that executes the query will be killed abruptly. In that case, query timeout > needs to tolerated till the query is active for some time before it can be > cancelled. This will avoid disruption to connection and hence normal > functioning of the application -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3331) JDBC T4 driver to support login timeout and query timeout
Selvaganesan Govindarajan created TRAFODION-3331: Summary: JDBC T4 driver to support login timeout and query timeout Key: TRAFODION-3331 URL: https://issues.apache.org/jira/browse/TRAFODION-3331 Project: Apache Trafodion Issue Type: Bug Reporter: Selvaganesan Govindarajan JDBC T4 driver lacks in functionality to support login timeout and query timeout. In addition the query timeout needs to sync up with cancelling query functionality in Trafodion SQL engine. It is possible that graceful query cancel is disabled in the Trafodion SQL engine. In that the process that executes the query will be killed abruptly. In that case, query timeout needs to tolerated till the query is active for some time before it can be cancelled. This will avoid disruption to connection and hence normal functioning of the application -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3328) Code cleanup in Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3328: - Description: Trafodion code base has many code paths that are unused due to legacy reasons. This Jira will be used to track all the tasks associated with this cleanup effort was: With embedded compiler, there is a need to have many cmpContexts to compile the query because the compile code is not re-entrant. With many cmpContext, there is a need to ensure the elements of cmpContext are managed in an optimal way. This Jira is created to track all the improvements that can be done in this area. > Code cleanup in Trafodion > - > > Key: TRAFODION-3328 > URL: https://issues.apache.org/jira/browse/TRAFODION-3328 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Trafodion code base has many code paths that are unused due to legacy > reasons. This Jira will be used to track all the tasks associated with this > cleanup effort > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3330) Cleanup of NADefaults
[ https://issues.apache.org/jira/browse/TRAFODION-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3330: - Description: With embedded compiler, there is a need to have many cmpContexts to compile the query because the compile code is not re-entrant. With many cmpContext, there is a need to ensure the elements of cmpContext are managed in an optimal way. This Jira is created to track all the improvements that can be done in this area. > Cleanup of NADefaults > - > > Key: TRAFODION-3330 > URL: https://issues.apache.org/jira/browse/TRAFODION-3330 > Project: Apache Trafodion > Issue Type: Sub-task > Components: sql-cmp >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > With embedded compiler, there is a need to have many cmpContexts to compile > the query because the compile code is not re-entrant. > With many cmpContext, there is a need to ensure the elements of cmpContext > are managed in an optimal way. This Jira is created to track all the > improvements that can be done in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3330) Cleanup of NADefaults
Selvaganesan Govindarajan created TRAFODION-3330: Summary: Cleanup of NADefaults Key: TRAFODION-3330 URL: https://issues.apache.org/jira/browse/TRAFODION-3330 Project: Apache Trafodion Issue Type: Sub-task Components: sql-cmp Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3329) Remove unused code in T2 driver
Selvaganesan Govindarajan created TRAFODION-3329: Summary: Remove unused code in T2 driver Key: TRAFODION-3329 URL: https://issues.apache.org/jira/browse/TRAFODION-3329 Project: Apache Trafodion Issue Type: Sub-task Components: client-jdbc-t2 Reporter: Selvaganesan Govindarajan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3328) Code cleanup in Trafodion
[ https://issues.apache.org/jira/browse/TRAFODION-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3328: - Summary: Code cleanup in Trafodion (was: Code cleanup in NADefaults) > Code cleanup in Trafodion > - > > Key: TRAFODION-3328 > URL: https://issues.apache.org/jira/browse/TRAFODION-3328 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > With embedded compiler, there is a need to have many cmpContexts to compile > the query because the compile code is not re-entrant. > With many cmpContext, there is a need to ensure the elements of cmpContext > are managed in an optimal way. This Jira is created to track all the > improvements that can be done in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (TRAFODION-3328) Code cleanup in NADefaults
[ https://issues.apache.org/jira/browse/TRAFODION-3328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan reassigned TRAFODION-3328: Assignee: Selvaganesan Govindarajan > Code cleanup in NADefaults > -- > > Key: TRAFODION-3328 > URL: https://issues.apache.org/jira/browse/TRAFODION-3328 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > With embedded compiler, there is a need to have many cmpContexts to compile > the query because the compile code is not re-entrant. > With many cmpContext, there is a need to ensure the elements of cmpContext > are managed in an optimal way. This Jira is created to track all the > improvements that can be done in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3328) Code cleanup in NADefaults
Selvaganesan Govindarajan created TRAFODION-3328: Summary: Code cleanup in NADefaults Key: TRAFODION-3328 URL: https://issues.apache.org/jira/browse/TRAFODION-3328 Project: Apache Trafodion Issue Type: Improvement Components: sql-cmp Reporter: Selvaganesan Govindarajan With embedded compiler, there is a need to have many cmpContexts to compile the query because the compile code is not re-entrant. With many cmpContext, there is a need to ensure the elements of cmpContext are managed in an optimal way. This Jira is created to track all the improvements that can be done in this area. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TRAFODION-3327) LOB support in T2 driver
[ https://issues.apache.org/jira/browse/TRAFODION-3327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3327: - Description: LOB support in T2 driver doesn't use the concepts of LOB in Trafodion SQL engine. The existing code used the legacy code that was inherited from HP that couldn't be used with new CLOB/BLOB concepts in Trafodion SQL engine. > LOB support in T2 driver > > > Key: TRAFODION-3327 > URL: https://issues.apache.org/jira/browse/TRAFODION-3327 > Project: Apache Trafodion > Issue Type: New Feature > Components: client-jdbc-t2 >Reporter: Selvaganesan Govindarajan >Priority: Major > > LOB support in T2 driver doesn't use the concepts of LOB in Trafodion SQL > engine. The existing code used the legacy code that was inherited from HP > that couldn't be used with new CLOB/BLOB concepts in Trafodion SQL engine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3327) LOB support in T2 driver
Selvaganesan Govindarajan created TRAFODION-3327: Summary: LOB support in T2 driver Key: TRAFODION-3327 URL: https://issues.apache.org/jira/browse/TRAFODION-3327 Project: Apache Trafodion Issue Type: New Feature Components: client-jdbc-t2 Reporter: Selvaganesan Govindarajan -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TRAFODION-3311) Trafodion to start transactions for select statements with FOR UPDATE
Selvaganesan Govindarajan created TRAFODION-3311: Summary: Trafodion to start transactions for select statements with FOR UPDATE Key: TRAFODION-3311 URL: https://issues.apache.org/jira/browse/TRAFODION-3311 Project: Apache Trafodion Issue Type: Improvement Components: sql-general Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Currently, Trafodion doesn't start transactions for any select statement. However the standard seem to imply the transaction needs to be started for select. See Ansi SQL 92 spec at [http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt] Trafodion uses MVCC for concurrency control and uses 2 phase commit to rollback conflicting transactions. To avoid many conflicting access, the transaction will be started with FOR UPDATE select statements -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TRAFODION-3274) At times sqlci or any other SQL process fails to come up and dumps core
[ https://issues.apache.org/jira/browse/TRAFODION-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-3274. -- Resolution: Fixed This issue was fixed via [https://github.com/apache/trafodion/pull/1795] > At times sqlci or any other SQL process fails to come up and dumps core > --- > > Key: TRAFODION-3274 > URL: https://issues.apache.org/jira/browse/TRAFODION-3274 > Project: Apache Trafodion > Issue Type: Bug > Components: foundation >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > sqlci dumps core with the following stack trace > Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)): > #0 0x7f7d70071495 in raise () from /lib64/libc.so.6 > #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6 > #2 0x7f7d69232b02 in sb_util_assert_fun_com (pv_assert=ASSERT_INTCMP, > pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pp_op=0x7f7d69239b71 "!=", > pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348, > pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*, > int, int, int, void*)") at util.cpp:274 > #3 0x7f7d69232f23 in SB_util_assert_fun_ine (pp_exp=0x7f7d6fe0fcd2 > "lv_err != -1", pv_lhs=-1, pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", > pv_line=348, pp_fun=0x7f7d6fe109c0 "void > SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at > util.cpp:480 > #4 0x7f7d6fdebcbb in SB_Trans::Sock_Controller::epoll_ctl > (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", > pv_op=1, pv_fd=16, pv_event=1, pp_data=0x1ed3150) at sock.cpp:348 > #5 0x7f7d6fdec585 in SB_Trans::Sock_Controller::sock_add > (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", > pv_sock=16, pp_eh=0x1ed3150) at sock.cpp:593 > #6 0x7f7d6fdedf95 in SB_Trans::Sock_User_Common::event_init > (this=0x1ed2180, pp_eh=0x1ed3150) at sock.cpp:1060 > #7 0x7f7d6fdef3bc in SB_Trans::Sock_Stream::create > (pp_name=0x7f7d63ddb0f0 "connect p-id=0/40881/17 ($TM0-tm)", > pp_pname=0x7f7d63ddb5a0 "$TM0", pp_prog=0x7f7d63ddb420 "tm", pv_ic=false, > pp_sock=0x1ed2180, pv_mon_callback=0, pv_mon_unsol_callback=0, > pv_ms_comp_callback=0x7f7d6fdb8e74 , > pv_ms_abandon_callback=0x7f7d6fdb7a50 , > pv_ms_oc_callback=0x7f7d6fdcfdc8 , > pv_ms_lim_callback=0, pp_ms_recv_q=0x7f7d7002cfe0, > pp_ms_lim_q=0x7f7d7002cee0, pp_event_mgr=0x7f7d7002cd58, pv_open_nid=-1, > pv_open_pid=-1, pv_open_verif=-1, pv_opened_nid=0, pv_opened_pid=40881, > pv_opened_verif=17, pv_opened_type=2) at sockstream.cpp:435 > #8 0x7f7d6fdd16b5 in msg_mon_open_process_com_ph2_sock > (pp_where=0x7f7d6fe09921 "msg_mon_open_process-ph2", pp_name=0x7f7d63ddb5a0 > "$TM0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, > pv_ic=false, pp_od=0x1ed4c20, pp_msg=0x7f7d6494268c, pv_nid=0, pv_pid=40881, > pv_verif=17, pv_ptype=2) at msmon.cpp:5113 > #9 0x7f7d6fdd124d in msg_mon_open_process_com_ph2 > (pp_name=0x7f7d63ddb5a0 "$TM0", pp_phandle=0x7f7d63ddb6c0, > pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_death_notif=true, pv_ic=false, > pp_od=0x1ed4c20) at msmon.cpp:4989 > #10 0x7f7d6fdd076c in msg_mon_open_process_com (pp_name=0x7f7d63ddb720 > "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, > pv_death_notif=true, pv_self=false, pv_backup=false, pv_ic=false, > pv_fs_open=false) at msmon.cpp:4724 > #11 0x7f7d6fdcfac8 in msg_mon_open_process (pp_name=0x7f7d63ddb720 > "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c) at msmon.cpp:4358 > #12 0x7f7d70da1af6 in TMLIB::open_tm (this=0x7f7d70fb8f80, pv_node=0, > pv_startup=) at tmlib.cpp:3070 > #13 0x7f7d70da19cc in TMLIB::initialize (this=0x7f7d70fb8f80) at > tmlib.cpp:2970 > #14 0x7f7d70da7e8c in tmlib_check_active_tx () at tmlib.cpp:262 > #15 0x7f7d70da8439 in GETTRANSID (pp_transid=0x7f7d63ddb828) at > tmlib.cpp:1091 > #16 0x7f7d7664744d in ExTransaction::getCurrentXnId (this= optimized out>, tcbref=, transId=0x7f7d63ddb820, > txHandle=0x7f7d63ddb800) at ../executor/ex_transaction.cpp:180 > #17 0x7f7d766475cc in ExTransaction::inheritTransaction > (this=0x7f7d632ded80) at ../executor/ex_transaction.cpp:770 > #18 0x7f7d76d891cd in CliPrologue (cliGlobals=0x1eb77a0, module= optimized out>) at ../cli/Cli.cpp:431 > #19 0x7f7d76d8cae4 in SQLCLI_GetAuthID (cliGlobals=0x1eb77a0, > authName=0x1ea0350 "SQL_USER1", authID=@0x7f7d63ddba68) at ../cli/Cli.cpp:6195 > #20 0x7f7d76e19b60 in SQL_EXEC_GetAuthID (authName=0x1ea0350 "SQL_USER1", > authID=@0x7f7d63ddba68) at ../cli/CliExtern.cpp:4117 > #21 0x7f7d78655a5b in SqlciEnv::setUserIdentityInCLI (this=0x1ea0240) at >
[jira] [Created] (TRAFODION-3310) Commit transaction needs to be complete before returning to the caller
Selvaganesan Govindarajan created TRAFODION-3310: Summary: Commit transaction needs to be complete before returning to the caller Key: TRAFODION-3310 URL: https://issues.apache.org/jira/browse/TRAFODION-3310 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan There is a potential issue that commit work command might be returned before it is actually done. The TM layer returns early for the "COMMIT_TRANSACTION" API based on the environment variable setting -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3280) Reduce path length in Trafodion for improved performance and scalability
Selvaganesan Govindarajan created TRAFODION-3280: Summary: Reduce path length in Trafodion for improved performance and scalability Key: TRAFODION-3280 URL: https://issues.apache.org/jira/browse/TRAFODION-3280 Project: Apache Trafodion Issue Type: Improvement Components: sql-general Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan To improve OLTP kind of queries, a sample application was profiled to determine the unnecessary dominant functions in Trafodion. It is found that # JULIANTIMESTAMP was abnormally taking longer path length. # Unnecessary memset after malloc because new and delete operators were overloaded. This Jira will act as covering Jira for future enhancements too -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TRAFODION-3274) At times sqlci or any other SQL process fails to come up and dumps core
[
https://issues.apache.org/jira/browse/TRAFODION-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16765611#comment-16765611
]
Selvaganesan Govindarajan commented on TRAFODION-3274:
--
The analysis of the core dump is as follows:
It looks like epoll fd is invalid and hence EINVAL is returned at the time of
epoll_ctl API. Epoll_fd is initialized in the global object gv_sock_ctrl. From
the dump,
(gdb) p gv_sock_ctlr
$5 = {
_vptr.Sock_Controller = 0x7f7d700287b0,
ip_comp_thread = 0x0,
ip_shutdown_eh = 0x0,
iv_ctlr_mutex = {
_vptr.Mutex = 0x7f7d69440630,
iv_destroyed = false,
iv_mutex = {
__data = {
__lock = 0,
__count = 0,
__owner = 0,
__nusers = 0,
__kind = 0,
__spins = 0,
__list = {
__prev = 0x0,
__next = 0x0
}
},
__size = '\000' ,
__align = 0
},
ip_mutex_name = 0x0,
iv_errorcheck = false,
iv_recursive = false
},
*_iv_efd = 2_*
}
Supposedly stderr fd of 2 is then assigned to different file possibly during
error redirection.
(gdb) p *stderr
$6 = {
_flags = -72537977,
_IO_read_ptr = 0x7f7d703ce1a3 "",
_IO_read_end = 0x7f7d703ce1a3 "",
_IO_read_base = 0x7f7d703ce1a3 "",
_IO_write_base = 0x7f7d703ce1a3 "",
_IO_write_ptr = 0x7f7d703ce1a3 "",
_IO_write_end = 0x7f7d703ce1a3 "",
_IO_buf_base = 0x7f7d703ce1a3 "",
_IO_buf_end = 0x7f7d703ce1a4 "",
_IO_save_base = 0x0,
_IO_backup_base = 0x0,
_IO_save_end = 0x0,
_markers = 0x0,
_chain = 0x7f7d703ce040,
*_fileno = 2,*
_flags2 = 0,
_old_offset = -1,
_cur_column = 0,
_vtable_offset = 0 '\000',
_shortbuf = "",
_lock = 0x7f7d703cf6c0,
_offset = -1,
__pad1 = 0x0,
__pad2 = 0x7f7d703ce4e0,
__pad3 = 0x0,
__pad4 = 0x0,
__pad5 = 0,
_mode = -1,
_unused2 = '\000'
}
(gdb)
Hence, sqlci dumps core when epoll_ctl returns EINVAL Out of the possible
causes for EINVAL return for epoll_ctl,
*EINVAL* _epfd_ is not an *epoll* file descriptor, or _fd_ is the same as
_epfd_, or the requested operation _op_ is not supported by this interface.
.
I think there is some race condition in C++ main function prologue while
initializing the embedded global objects and the stdin, stdout and stderr file
descriptors. I haven’t looked at how stderr got redirected in our code. Most
likely it assumed the fd of 2 for stderr. This would explain why epoll_ctl
returned EINVAL.
I don’t suspect that the global variable gv_sock_ctrl got corrupted to have
iv_efd to be 2, though I can’t explain why isn’t.
Possible solutions are:
# Make gv_sock_ctrl as a pointer and construct it when accessed for the first
time in seabed layer
# Make our redirector code to use proper stderr fd for redirection.
> At times sqlci or any other SQL process fails to come up and dumps core
> ---
>
> Key: TRAFODION-3274
> URL: https://issues.apache.org/jira/browse/TRAFODION-3274
> Project: Apache Trafodion
> Issue Type: Bug
> Components: foundation
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
>Priority: Major
>
> sqlci dumps core with the following stack trace
> Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)):
> #0 0x7f7d70071495 in raise () from /lib64/libc.so.6
> #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6
> #2 0x7f7d69232b02 in sb_util_assert_fun_com (pv_assert=ASSERT_INTCMP,
> pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pp_op=0x7f7d69239b71 "!=",
> pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348,
> pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*,
> int, int, int, void*)") at util.cpp:274
> #3 0x7f7d69232f23 in SB_util_assert_fun_ine (pp_exp=0x7f7d6fe0fcd2
> "lv_err != -1", pv_lhs=-1, pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp",
> pv_line=348, pp_fun=0x7f7d6fe109c0 "void
> SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at
> util.cpp:480
> #4 0x7f7d6fdebcbb in SB_Trans::Sock_Controller::epoll_ctl
> (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init",
> pv_op=1, pv_fd=16, pv_event=1, pp_data=0x1ed3150) at sock.cpp:348
> #5 0x7f7d6fdec585 in SB_Trans::Sock_Controller::sock_add
> (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init",
> pv_sock=16, pp_eh=0x1ed3150) at sock.cpp:593
> #6 0x7f7d6fdedf95 in SB_Trans::Sock_User_Common::event_init
> (this=0x1ed2180, pp_eh=0x1ed3150) at sock.cpp:1060
> #7 0x7f7d6fdef3bc in SB_Trans::Sock_Stream::create
> (pp_name=0x7f7d63ddb0f0 "connect p-id=0/40881/17 ($TM0-tm)",
> pp_pname=0x7f7d63ddb5a0 "$TM0", pp_prog=0x7f7d63ddb420 "tm", pv_ic=false,
[jira] [Updated] (TRAFODION-3274) At times sqlci or any other SQL process fails to come up and dumps core
[ https://issues.apache.org/jira/browse/TRAFODION-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3274: - Description: sqlci dumps core with the following stack trace Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)): #0 0x7f7d70071495 in raise () from /lib64/libc.so.6 #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6 #2 0x7f7d69232b02 in sb_util_assert_fun_com (pv_assert=ASSERT_INTCMP, pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pp_op=0x7f7d69239b71 "!=", pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348, pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at util.cpp:274 #3 0x7f7d69232f23 in SB_util_assert_fun_ine (pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348, pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at util.cpp:480 #4 0x7f7d6fdebcbb in SB_Trans::Sock_Controller::epoll_ctl (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", pv_op=1, pv_fd=16, pv_event=1, pp_data=0x1ed3150) at sock.cpp:348 #5 0x7f7d6fdec585 in SB_Trans::Sock_Controller::sock_add (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", pv_sock=16, pp_eh=0x1ed3150) at sock.cpp:593 #6 0x7f7d6fdedf95 in SB_Trans::Sock_User_Common::event_init (this=0x1ed2180, pp_eh=0x1ed3150) at sock.cpp:1060 #7 0x7f7d6fdef3bc in SB_Trans::Sock_Stream::create (pp_name=0x7f7d63ddb0f0 "connect p-id=0/40881/17 ($TM0-tm)", pp_pname=0x7f7d63ddb5a0 "$TM0", pp_prog=0x7f7d63ddb420 "tm", pv_ic=false, pp_sock=0x1ed2180, pv_mon_callback=0, pv_mon_unsol_callback=0, pv_ms_comp_callback=0x7f7d6fdb8e74 , pv_ms_abandon_callback=0x7f7d6fdb7a50 , pv_ms_oc_callback=0x7f7d6fdcfdc8 , pv_ms_lim_callback=0, pp_ms_recv_q=0x7f7d7002cfe0, pp_ms_lim_q=0x7f7d7002cee0, pp_event_mgr=0x7f7d7002cd58, pv_open_nid=-1, pv_open_pid=-1, pv_open_verif=-1, pv_opened_nid=0, pv_opened_pid=40881, pv_opened_verif=17, pv_opened_type=2) at sockstream.cpp:435 #8 0x7f7d6fdd16b5 in msg_mon_open_process_com_ph2_sock (pp_where=0x7f7d6fe09921 "msg_mon_open_process-ph2", pp_name=0x7f7d63ddb5a0 "$TM0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_ic=false, pp_od=0x1ed4c20, pp_msg=0x7f7d6494268c, pv_nid=0, pv_pid=40881, pv_verif=17, pv_ptype=2) at msmon.cpp:5113 #9 0x7f7d6fdd124d in msg_mon_open_process_com_ph2 (pp_name=0x7f7d63ddb5a0 "$TM0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_death_notif=true, pv_ic=false, pp_od=0x1ed4c20) at msmon.cpp:4989 #10 0x7f7d6fdd076c in msg_mon_open_process_com (pp_name=0x7f7d63ddb720 "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_death_notif=true, pv_self=false, pv_backup=false, pv_ic=false, pv_fs_open=false) at msmon.cpp:4724 #11 0x7f7d6fdcfac8 in msg_mon_open_process (pp_name=0x7f7d63ddb720 "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c) at msmon.cpp:4358 #12 0x7f7d70da1af6 in TMLIB::open_tm (this=0x7f7d70fb8f80, pv_node=0, pv_startup=) at tmlib.cpp:3070 #13 0x7f7d70da19cc in TMLIB::initialize (this=0x7f7d70fb8f80) at tmlib.cpp:2970 #14 0x7f7d70da7e8c in tmlib_check_active_tx () at tmlib.cpp:262 #15 0x7f7d70da8439 in GETTRANSID (pp_transid=0x7f7d63ddb828) at tmlib.cpp:1091 #16 0x7f7d7664744d in ExTransaction::getCurrentXnId (this=, tcbref=, transId=0x7f7d63ddb820, txHandle=0x7f7d63ddb800) at ../executor/ex_transaction.cpp:180 #17 0x7f7d766475cc in ExTransaction::inheritTransaction (this=0x7f7d632ded80) at ../executor/ex_transaction.cpp:770 #18 0x7f7d76d891cd in CliPrologue (cliGlobals=0x1eb77a0, module=) at ../cli/Cli.cpp:431 #19 0x7f7d76d8cae4 in SQLCLI_GetAuthID (cliGlobals=0x1eb77a0, authName=0x1ea0350 "SQL_USER1", authID=@0x7f7d63ddba68) at ../cli/Cli.cpp:6195 #20 0x7f7d76e19b60 in SQL_EXEC_GetAuthID (authName=0x1ea0350 "SQL_USER1", authID=@0x7f7d63ddba68) at ../cli/CliExtern.cpp:4117 #21 0x7f7d78655a5b in SqlciEnv::setUserIdentityInCLI (this=0x1ea0240) at ../sqlci/SqlciEnv.cpp:1426 #22 0x7f7d78656239 in SqlciEnv_prologue_to_run (sqlciEnv=0x1ea0240) at ../sqlci/SqlciEnv.cpp:513 #23 0x7f7d7865648c in SqlciEnv::run (this=0x1ea0240, in_filename=0x7ffcaf9a4a1d "TEST142(user1_cmds)", input_string=) at ../sqlci/SqlciEnv.cpp:654 #24 0x00401fde in thread_main (p_arg=) at ../bin/SqlciMain.cpp:333 #25 0x7f7d6f937aa1 in start_thread () from /lib64/libpthread.so.0 #26 0x7f7d70127bcd in clone () from /lib64/libc.so.6 was: Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)): #0 0x7f7d70071495 in raise () from /lib64/libc.so.6 #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6 #2 0x7f7d69232b02 in sb_util_assert_fun_com
[jira] [Updated] (TRAFODION-3274) At times sqlci or any other SQL process fails to come up and dumps core
[ https://issues.apache.org/jira/browse/TRAFODION-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3274: - Description: Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)): #0 0x7f7d70071495 in raise () from /lib64/libc.so.6 #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6 #2 0x7f7d69232b02 in sb_util_assert_fun_com (pv_assert=ASSERT_INTCMP, pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pp_op=0x7f7d69239b71 "!=", pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348, pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at util.cpp:274 #3 0x7f7d69232f23 in SB_util_assert_fun_ine (pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1, pv_rhs=-1, pp_file=0x7f7d6fe0fb7a "sock.cpp", pv_line=348, pp_fun=0x7f7d6fe109c0 "void SB_Trans::Sock_Controller::epoll_ctl(const char*, int, int, int, void*)") at util.cpp:480 #4 0x7f7d6fdebcbb in SB_Trans::Sock_Controller::epoll_ctl (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", pv_op=1, pv_fd=16, pv_event=1, pp_data=0x1ed3150) at sock.cpp:348 #5 0x7f7d6fdec585 in SB_Trans::Sock_Controller::sock_add (this=0x7f7d7003e560, pp_where=0x7f7d63ddad30 "Sock_Client::event_init", pv_sock=16, pp_eh=0x1ed3150) at sock.cpp:593 #6 0x7f7d6fdedf95 in SB_Trans::Sock_User_Common::event_init (this=0x1ed2180, pp_eh=0x1ed3150) at sock.cpp:1060 #7 0x7f7d6fdef3bc in SB_Trans::Sock_Stream::create (pp_name=0x7f7d63ddb0f0 "connect p-id=0/40881/17 ($TM0-tm)", pp_pname=0x7f7d63ddb5a0 "$TM0", pp_prog=0x7f7d63ddb420 "tm", pv_ic=false, pp_sock=0x1ed2180, pv_mon_callback=0, pv_mon_unsol_callback=0, pv_ms_comp_callback=0x7f7d6fdb8e74 , pv_ms_abandon_callback=0x7f7d6fdb7a50 , pv_ms_oc_callback=0x7f7d6fdcfdc8 , pv_ms_lim_callback=0, pp_ms_recv_q=0x7f7d7002cfe0, pp_ms_lim_q=0x7f7d7002cee0, pp_event_mgr=0x7f7d7002cd58, pv_open_nid=-1, pv_open_pid=-1, pv_open_verif=-1, pv_opened_nid=0, pv_opened_pid=40881, pv_opened_verif=17, pv_opened_type=2) at sockstream.cpp:435 #8 0x7f7d6fdd16b5 in msg_mon_open_process_com_ph2_sock (pp_where=0x7f7d6fe09921 "msg_mon_open_process-ph2", pp_name=0x7f7d63ddb5a0 "$TM0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_ic=false, pp_od=0x1ed4c20, pp_msg=0x7f7d6494268c, pv_nid=0, pv_pid=40881, pv_verif=17, pv_ptype=2) at msmon.cpp:5113 #9 0x7f7d6fdd124d in msg_mon_open_process_com_ph2 (pp_name=0x7f7d63ddb5a0 "$TM0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_death_notif=true, pv_ic=false, pp_od=0x1ed4c20) at msmon.cpp:4989 #10 0x7f7d6fdd076c in msg_mon_open_process_com (pp_name=0x7f7d63ddb720 "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c, pv_reopen=false, pv_death_notif=true, pv_self=false, pv_backup=false, pv_ic=false, pv_fs_open=false) at msmon.cpp:4724 #11 0x7f7d6fdcfac8 in msg_mon_open_process (pp_name=0x7f7d63ddb720 "$tm0", pp_phandle=0x7f7d63ddb6c0, pp_oid=0x7f7d63ddb72c) at msmon.cpp:4358 #12 0x7f7d70da1af6 in TMLIB::open_tm (this=0x7f7d70fb8f80, pv_node=0, pv_startup=) at tmlib.cpp:3070 #13 0x7f7d70da19cc in TMLIB::initialize (this=0x7f7d70fb8f80) at tmlib.cpp:2970 #14 0x7f7d70da7e8c in tmlib_check_active_tx () at tmlib.cpp:262 #15 0x7f7d70da8439 in GETTRANSID (pp_transid=0x7f7d63ddb828) at tmlib.cpp:1091 #16 0x7f7d7664744d in ExTransaction::getCurrentXnId (this=, tcbref=, transId=0x7f7d63ddb820, txHandle=0x7f7d63ddb800) at ../executor/ex_transaction.cpp:180 #17 0x7f7d766475cc in ExTransaction::inheritTransaction (this=0x7f7d632ded80) at ../executor/ex_transaction.cpp:770 #18 0x7f7d76d891cd in CliPrologue (cliGlobals=0x1eb77a0, module=) at ../cli/Cli.cpp:431 #19 0x7f7d76d8cae4 in SQLCLI_GetAuthID (cliGlobals=0x1eb77a0, authName=0x1ea0350 "SQL_USER1", authID=@0x7f7d63ddba68) at ../cli/Cli.cpp:6195 #20 0x7f7d76e19b60 in SQL_EXEC_GetAuthID (authName=0x1ea0350 "SQL_USER1", authID=@0x7f7d63ddba68) at ../cli/CliExtern.cpp:4117 #21 0x7f7d78655a5b in SqlciEnv::setUserIdentityInCLI (this=0x1ea0240) at ../sqlci/SqlciEnv.cpp:1426 #22 0x7f7d78656239 in SqlciEnv_prologue_to_run (sqlciEnv=0x1ea0240) at ../sqlci/SqlciEnv.cpp:513 #23 0x7f7d7865648c in SqlciEnv::run (this=0x1ea0240, in_filename=0x7ffcaf9a4a1d "TEST142(user1_cmds)", input_string=) at ../sqlci/SqlciEnv.cpp:654 #24 0x00401fde in thread_main (p_arg=) at ../bin/SqlciMain.cpp:333 #25 0x7f7d6f937aa1 in start_thread () from /lib64/libpthread.so.0 #26 0x7f7d70127bcd in clone () from /lib64/libc.so.6 Thread 1 (Thread 0x7f7d63dde700 (LWP 58936)): #0 0x7f7d70071495 in raise () from /lib64/libc.so.6 #1 0x7f7d70072c75 in abort () from /lib64/libc.so.6 #2 0x7f7d69232b02 in sb_util_assert_fun_com (pv_assert=ASSERT_INTCMP, pp_exp=0x7f7d6fe0fcd2 "lv_err != -1", pv_lhs=-1,
[jira] [Created] (TRAFODION-3274) At times sqlci or any other SQL process fails to come up and dumps core
Selvaganesan Govindarajan created TRAFODION-3274: Summary: At times sqlci or any other SQL process fails to come up and dumps core Key: TRAFODION-3274 URL: https://issues.apache.org/jira/browse/TRAFODION-3274 Project: Apache Trafodion Issue Type: Bug Components: foundation Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TRAFODION-3234) Refactor hive meta calls to be less resource intensive to support hive partitions if needed
[ https://issues.apache.org/jira/browse/TRAFODION-3234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3234: - Summary: Refactor hive meta calls to be less resource intensive to support hive partitions if needed (was: Add support for hive partitioned table) > Refactor hive meta calls to be less resource intensive to support hive > partitions if needed > --- > > Key: TRAFODION-3234 > URL: https://issues.apache.org/jira/browse/TRAFODION-3234 > Project: Apache Trafodion > Issue Type: Improvement > Components: sql-cmp, sql-exe >Affects Versions: 2.4 >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > Currently Trafodion doesn't support partitioned hive tables. To start with, > added a code to get full meta data information about the hive table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3234) Add support for hive partitioned table
Selvaganesan Govindarajan created TRAFODION-3234: Summary: Add support for hive partitioned table Key: TRAFODION-3234 URL: https://issues.apache.org/jira/browse/TRAFODION-3234 Project: Apache Trafodion Issue Type: Improvement Components: sql-cmp, sql-exe Affects Versions: 2.4 Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Currently Trafodion doesn't support partitioned hive tables. To start with, added a code to get full meta data information about the hive table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TRAFODION-3225) Obscure cores seen in RMS and logger related code when Trafodion is stressed
[
https://issues.apache.org/jira/browse/TRAFODION-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16669026#comment-16669026
]
Selvaganesan Govindarajan commented on TRAFODION-3225:
--
Logger infrastructure in Trafodion is implemented via an internal class
QRLogger. QRLogger is a singleton instance in a process. It was suspected that
the singleton instance was getting clobbered somehow leading to all kinds of
issues with the logger
> Obscure cores seen in RMS and logger related code when Trafodion is stressed
>
>
> Key: TRAFODION-3225
> URL: https://issues.apache.org/jira/browse/TRAFODION-3225
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
>Priority: Major
>
> During stress testing of enterprise edition of Trafodion, the following
> problems are seen.
> {color:#00}Thread 1 (Thread 0x7efee4046700 (LWP 26304)):{color}
> {color:#00}#0 0x7eff1ad045f7 in raise () from /lib64/libc.so.6{color}
> {color:#00}#1 0x7eff1ad05e28 in abort () from /lib64/libc.so.6{color}
> {color:#00}#2 0x7eff1609b94e in assert_botch_abend (f=0x7eff1a7eac75
> "../cli/Statement.cpp", l=6178, m=0x7eff1a7eb9e0 "StmtStats_ is null after
> addQuery", c=0x0) at ../export/NAAbort.cpp:285{color}
> {color:#00}#3 0x7eff1a777df9 in Statement::setStmtStats
> (this=0x7efee2bd94d0, autoRetry=0) at ../cli/Statement.cpp:6178{color}
> {color:#00}#4 0x7eff1a6d08ed in SQLCLI_ExecDirect2(CliGlobals *,
> SQLSTMT_ID *, SQLDESC_ID *, Int32, SQLDESC_ID *, Lng32, typedef __va_list_tag
> __va_list_tag *, SQLCLI_PTR_PAIRS *) (cliGlobals=0x22691d0,
> statement_id=0x4d45068, sql_source=0x7efee40420f0, prepFlags=0,
> input_descriptor=0x0, num_ptr_pairs=0, ap=0x7efee4041e90, ptr_pairs=0x0) at
> ../cli/Cli.cpp:3317{color}
> {color:#00}#5 0x7eff1a789c88 in SQL_EXEC_ExecDirect2
> (statement_id=0x4d45068, sql_source=0x7efee40420f0, prep_flags=0,
> input_descriptor=0x0, num_ptr_pairs=0) at ../cli/CliExtern.cpp:2090{color}
> {color:#00}#6 0x7eff1d4c30ab in SRVR::WSQL_EXEC_ExecDirect
> (statement_id=0x4d45068, sql_source=0x7efee40420f0, input_descriptor=0x0,
> num_ptr_pairs=0) at SQLWrapper.cpp:364{color}
> {color:#00}#7 0x7eff1d4aaa8b in SRVR::EXECDIRECT
> (pSrvrStmt=0x4d44a50) at sqlinterface.cpp:4700{color}
> {color:#00}#8 0x7eff1d438280 in SRVR::ControlProc (pParam=0x4d44a50)
> at csrvrstmt.cpp:768{color}
> {color:#00}#9 0x7eff1d4378b7 in SRVR_STMT_HDL::ExecDirect
> (this=0x4d44a50, inCursorName=0x0, inSqlString=0x5f64aa8 "update
> Trafodion.\"_REPOS_\".metric_query_aggr_table set
> AGGREGATION_LAST_UPDATE_UTC_TS =
> CONVERTTIMESTAMP(212406077134960312),AGGREGATION_LAST_ELAPSED_TIME =
> 6,TOTAL_EST_ROWS_ACCESSED = 0,TOTAL_EST"..., inStmtType=1,
> inSqlStmtType=0, inSqlAsyncEnable=0, inQueryTimeout=0) at
> csrvrstmt.cpp:450{color}
> {color:#00}#10 0x0056f059 in SessionWatchDog (arg=0x0) at
> SrvrConnect.cpp:1194{color}
> {color:#00}#11 0x7eff1dbe1dc5 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#00}#12 0x7eff1adc5ced in clone () from /lib64/libc.so.6{color}
>
> {color:#00}And other obscure cores related to ExStatisticsArea.{color}
> {color:#00} {color}
> {color:#00}The logger infrastructure fails with the following stack trace
> or some other variations in the logger code.{color}
>
> #0 0x7f4afb8bb495 in raise () from /lib64/libc.so.6
> #1 0x7f4afb8bcc75 in abort () from /lib64/libc.so.6
> #2 0x7f4afa705a8d in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib64/libstdc++.so.6
> #3 0x7f4afa703be6 in ?? () from /usr/lib64/libstdc++.so.6
> #4 0x7f4afa703c13 in std::terminate() () from /usr/lib64/libstdc++.so.6
> #5 0x7f4afa70456f in __cxa_pure_virtual () from /usr/lib64/libstdc++.so.6
> #6 0x7f4afb203f60 in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #7 0x7f4afb38ba9f in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #8 0x7f4afb38d47f in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #9 0x7f4afb200ef2 in JVM_handle_linux_signal () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #10 0x7f4afb1f6753 in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #11
> #12 0x7f4ad6561e2c in log4cxx::helpers::Transcoder::decode (src=
>
>
[jira] [Commented] (TRAFODION-3225) Obscure cores seen in RMS and logger related code when Trafodion is stressed
[
https://issues.apache.org/jira/browse/TRAFODION-3225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16669020#comment-16669020
]
Selvaganesan Govindarajan commented on TRAFODION-3225:
--
The RMS related core dumps is diagnosed as follows:
The query fragment or the registered process in the shared segment is
deregistered in the shared segment though the process continues to exist. Hence
the stale references to the shared segment in the process causes core dump and
at times can bring down the trafodion node.
> Obscure cores seen in RMS and logger related code when Trafodion is stressed
>
>
> Key: TRAFODION-3225
> URL: https://issues.apache.org/jira/browse/TRAFODION-3225
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
>Reporter: Selvaganesan Govindarajan
>Assignee: Selvaganesan Govindarajan
>Priority: Major
>
> During stress testing of enterprise edition of Trafodion, the following
> problems are seen.
> {color:#00}Thread 1 (Thread 0x7efee4046700 (LWP 26304)):{color}
> {color:#00}#0 0x7eff1ad045f7 in raise () from /lib64/libc.so.6{color}
> {color:#00}#1 0x7eff1ad05e28 in abort () from /lib64/libc.so.6{color}
> {color:#00}#2 0x7eff1609b94e in assert_botch_abend (f=0x7eff1a7eac75
> "../cli/Statement.cpp", l=6178, m=0x7eff1a7eb9e0 "StmtStats_ is null after
> addQuery", c=0x0) at ../export/NAAbort.cpp:285{color}
> {color:#00}#3 0x7eff1a777df9 in Statement::setStmtStats
> (this=0x7efee2bd94d0, autoRetry=0) at ../cli/Statement.cpp:6178{color}
> {color:#00}#4 0x7eff1a6d08ed in SQLCLI_ExecDirect2(CliGlobals *,
> SQLSTMT_ID *, SQLDESC_ID *, Int32, SQLDESC_ID *, Lng32, typedef __va_list_tag
> __va_list_tag *, SQLCLI_PTR_PAIRS *) (cliGlobals=0x22691d0,
> statement_id=0x4d45068, sql_source=0x7efee40420f0, prepFlags=0,
> input_descriptor=0x0, num_ptr_pairs=0, ap=0x7efee4041e90, ptr_pairs=0x0) at
> ../cli/Cli.cpp:3317{color}
> {color:#00}#5 0x7eff1a789c88 in SQL_EXEC_ExecDirect2
> (statement_id=0x4d45068, sql_source=0x7efee40420f0, prep_flags=0,
> input_descriptor=0x0, num_ptr_pairs=0) at ../cli/CliExtern.cpp:2090{color}
> {color:#00}#6 0x7eff1d4c30ab in SRVR::WSQL_EXEC_ExecDirect
> (statement_id=0x4d45068, sql_source=0x7efee40420f0, input_descriptor=0x0,
> num_ptr_pairs=0) at SQLWrapper.cpp:364{color}
> {color:#00}#7 0x7eff1d4aaa8b in SRVR::EXECDIRECT
> (pSrvrStmt=0x4d44a50) at sqlinterface.cpp:4700{color}
> {color:#00}#8 0x7eff1d438280 in SRVR::ControlProc (pParam=0x4d44a50)
> at csrvrstmt.cpp:768{color}
> {color:#00}#9 0x7eff1d4378b7 in SRVR_STMT_HDL::ExecDirect
> (this=0x4d44a50, inCursorName=0x0, inSqlString=0x5f64aa8 "update
> Trafodion.\"_REPOS_\".metric_query_aggr_table set
> AGGREGATION_LAST_UPDATE_UTC_TS =
> CONVERTTIMESTAMP(212406077134960312),AGGREGATION_LAST_ELAPSED_TIME =
> 6,TOTAL_EST_ROWS_ACCESSED = 0,TOTAL_EST"..., inStmtType=1,
> inSqlStmtType=0, inSqlAsyncEnable=0, inQueryTimeout=0) at
> csrvrstmt.cpp:450{color}
> {color:#00}#10 0x0056f059 in SessionWatchDog (arg=0x0) at
> SrvrConnect.cpp:1194{color}
> {color:#00}#11 0x7eff1dbe1dc5 in start_thread () from
> /lib64/libpthread.so.0{color}
> {color:#00}#12 0x7eff1adc5ced in clone () from /lib64/libc.so.6{color}
>
> {color:#00}And other obscure cores related to ExStatisticsArea.{color}
> {color:#00} {color}
> {color:#00}The logger infrastructure fails with the following stack trace
> or some other variations in the logger code.{color}
>
> #0 0x7f4afb8bb495 in raise () from /lib64/libc.so.6
> #1 0x7f4afb8bcc75 in abort () from /lib64/libc.so.6
> #2 0x7f4afa705a8d in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib64/libstdc++.so.6
> #3 0x7f4afa703be6 in ?? () from /usr/lib64/libstdc++.so.6
> #4 0x7f4afa703c13 in std::terminate() () from /usr/lib64/libstdc++.so.6
> #5 0x7f4afa70456f in __cxa_pure_virtual () from /usr/lib64/libstdc++.so.6
> #6 0x7f4afb203f60 in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #7 0x7f4afb38ba9f in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #8 0x7f4afb38d47f in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #9 0x7f4afb200ef2 in JVM_handle_linux_signal () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #10 0x7f4afb1f6753 in ?? () from
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
> #11
> #12 0x7f4ad6561e2c in
[jira] [Created] (TRAFODION-3225) Obscure cores seen in RMS and logger related code when Trafodion is stressed
Selvaganesan Govindarajan created TRAFODION-3225:
Summary: Obscure cores seen in RMS and logger related code when
Trafodion is stressed
Key: TRAFODION-3225
URL: https://issues.apache.org/jira/browse/TRAFODION-3225
Project: Apache Trafodion
Issue Type: Bug
Components: sql-exe
Reporter: Selvaganesan Govindarajan
Assignee: Selvaganesan Govindarajan
During stress testing of enterprise edition of Trafodion, the following
problems are seen.
{color:#00}Thread 1 (Thread 0x7efee4046700 (LWP 26304)):{color}
{color:#00}#0 0x7eff1ad045f7 in raise () from /lib64/libc.so.6{color}
{color:#00}#1 0x7eff1ad05e28 in abort () from /lib64/libc.so.6{color}
{color:#00}#2 0x7eff1609b94e in assert_botch_abend (f=0x7eff1a7eac75
"../cli/Statement.cpp", l=6178, m=0x7eff1a7eb9e0 "StmtStats_ is null after
addQuery", c=0x0) at ../export/NAAbort.cpp:285{color}
{color:#00}#3 0x7eff1a777df9 in Statement::setStmtStats
(this=0x7efee2bd94d0, autoRetry=0) at ../cli/Statement.cpp:6178{color}
{color:#00}#4 0x7eff1a6d08ed in SQLCLI_ExecDirect2(CliGlobals *,
SQLSTMT_ID *, SQLDESC_ID *, Int32, SQLDESC_ID *, Lng32, typedef __va_list_tag
__va_list_tag *, SQLCLI_PTR_PAIRS *) (cliGlobals=0x22691d0,
statement_id=0x4d45068, sql_source=0x7efee40420f0, prepFlags=0,
input_descriptor=0x0, num_ptr_pairs=0, ap=0x7efee4041e90, ptr_pairs=0x0) at
../cli/Cli.cpp:3317{color}
{color:#00}#5 0x7eff1a789c88 in SQL_EXEC_ExecDirect2
(statement_id=0x4d45068, sql_source=0x7efee40420f0, prep_flags=0,
input_descriptor=0x0, num_ptr_pairs=0) at ../cli/CliExtern.cpp:2090{color}
{color:#00}#6 0x7eff1d4c30ab in SRVR::WSQL_EXEC_ExecDirect
(statement_id=0x4d45068, sql_source=0x7efee40420f0, input_descriptor=0x0,
num_ptr_pairs=0) at SQLWrapper.cpp:364{color}
{color:#00}#7 0x7eff1d4aaa8b in SRVR::EXECDIRECT (pSrvrStmt=0x4d44a50)
at sqlinterface.cpp:4700{color}
{color:#00}#8 0x7eff1d438280 in SRVR::ControlProc (pParam=0x4d44a50)
at csrvrstmt.cpp:768{color}
{color:#00}#9 0x7eff1d4378b7 in SRVR_STMT_HDL::ExecDirect
(this=0x4d44a50, inCursorName=0x0, inSqlString=0x5f64aa8 "update
Trafodion.\"_REPOS_\".metric_query_aggr_table set
AGGREGATION_LAST_UPDATE_UTC_TS =
CONVERTTIMESTAMP(212406077134960312),AGGREGATION_LAST_ELAPSED_TIME =
6,TOTAL_EST_ROWS_ACCESSED = 0,TOTAL_EST"..., inStmtType=1, inSqlStmtType=0,
inSqlAsyncEnable=0, inQueryTimeout=0) at csrvrstmt.cpp:450{color}
{color:#00}#10 0x0056f059 in SessionWatchDog (arg=0x0) at
SrvrConnect.cpp:1194{color}
{color:#00}#11 0x7eff1dbe1dc5 in start_thread () from
/lib64/libpthread.so.0{color}
{color:#00}#12 0x7eff1adc5ced in clone () from /lib64/libc.so.6{color}
{color:#00}And other obscure cores related to ExStatisticsArea.{color}
{color:#00} {color}
{color:#00}The logger infrastructure fails with the following stack trace
or some other variations in the logger code.{color}
#0 0x7f4afb8bb495 in raise () from /lib64/libc.so.6
#1 0x7f4afb8bcc75 in abort () from /lib64/libc.so.6
#2 0x7f4afa705a8d in __gnu_cxx::__verbose_terminate_handler() () from
/usr/lib64/libstdc++.so.6
#3 0x7f4afa703be6 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x7f4afa703c13 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x7f4afa70456f in __cxa_pure_virtual () from /usr/lib64/libstdc++.so.6
#6 0x7f4afb203f60 in ?? () from
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
#7 0x7f4afb38ba9f in ?? () from
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
#8 0x7f4afb38d47f in ?? () from
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
#9 0x7f4afb200ef2 in JVM_handle_linux_signal () from
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
#10 0x7f4afb1f6753 in ?? () from
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.161-3.b14.el6_9.x86_64/jre/lib/amd64/server/libjvm.so
#11
#12 0x7f4ad6561e2c in log4cxx::helpers::Transcoder::decode (src=
"SQL.HBas0\000\000\000\000\000\000\000\060\000\000\000\000\000\000\000\200yh\002\000\000\000\000\b\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000SQL.HDFS`\000\000\000\000\000\000\000\060\000\000\000\000\000\000\000\020eh\002\000\000\000\000\016\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000SQL.EXE.0\005\000\000\000\000\000\000@\000\000\000\000\000\000\000\200\210\210\004\000\000\000\000\a\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000SQL.Qmp\000\376\377\377\377\066\300\n\360org.apacp\005\000\000\000\000\000\000\060\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\017",
'\000' , "orc_proto.proto\000A", '\000'
[jira] [Commented] (TRAFODION-3187) ref count of ComDiagsArea is not increased
[
https://issues.apache.org/jira/browse/TRAFODION-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588918#comment-16588918
]
Selvaganesan Govindarajan commented on TRAFODION-3187:
--
It will be good to add a test case or the symptom of the problem that enabled
you to arrive at the conclusion in the JIRA. The symptom will enable the users
to pick up this patch if they happen to hit the same issue. Otherwise, users
wouldn't know when to pick up this patch
> ref count of ComDiagsArea is not increased
> ---
>
> Key: TRAFODION-3187
> URL: https://issues.apache.org/jira/browse/TRAFODION-3187
> Project: Apache Trafodion
> Issue Type: Bug
> Components: -exe
>Affects Versions: 2.4
>Reporter: Wenjun Zhu
>Assignee: Wenjun Zhu
>Priority: Minor
> Fix For: 2.4
>
>
> code of ExTupleFlowTcb::work() in core/sql/executor/ex_tuple_flow.cpp
> {code:java}
> 308 if ((pstate.tgtRowsSent_ == FALSE) &&
> 309 (src_entry->getDiagsArea()))
> 310 {
> 311 // a warning is returned with EOD and
> 312 // nothing else was returned from source.
> 313 // Move warning to parent's up queue.
> 314 if (qParent_.up->isFull())
> 315 return WORK_OK;
> 316
> 317 ex_queue_entry * up_entry =
> 318 qParent_.up->getTailEntry();
> 319 up_entry->setDiagsArea(src_entry->getDiagsArea());
> 320 }
> {code}
> has not increased the ref count, compared to the following correct one:
>
> {code:java}
> 294 if (from->getDiagsArea())
> 295 from->getDiagsArea()->incrRefCount();
> 296
> 297 setDiagsArea(from->getDiagsArea());
> {code}
> of atp_struct::copyAtp() in ore/sql/exp/ExpAtp.h
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TRAFODION-3185) Support splitting of Compressed Sequence file
[ https://issues.apache.org/jira/browse/TRAFODION-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3185: - Summary: Support splitting of Compressed Sequence file (was: Support split of Compressed Sequence file ) > Support splitting of Compressed Sequence file > -- > > Key: TRAFODION-3185 > URL: https://issues.apache.org/jira/browse/TRAFODION-3185 > Project: Apache Trafodion > Issue Type: Sub-task > Components: sql-cmp, sql-exe >Affects Versions: 2.4 >Reporter: Selvaganesan Govindarajan >Priority: Major > > One of the feature of sequence file is the ability to split it for reading a > compressed sequence file. The compression can be done at a record or block > level. Trafodion needs to support the ability to split the compressed > sequence file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3185) Support split of Compressed Sequence file
Selvaganesan Govindarajan created TRAFODION-3185: Summary: Support split of Compressed Sequence file Key: TRAFODION-3185 URL: https://issues.apache.org/jira/browse/TRAFODION-3185 Project: Apache Trafodion Issue Type: Sub-task Components: sql-cmp, sql-exe Affects Versions: 2.4 Reporter: Selvaganesan Govindarajan One of the feature of sequence file is the ability to split it for reading a compressed sequence file. The compression can be done at a record or block level. Trafodion needs to support the ability to split the compressed sequence file. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TRAFODION-3171) Refactor Sequence File Reading to use the new implementation
[ https://issues.apache.org/jira/browse/TRAFODION-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3171: - Issue Type: Bug (was: Sub-task) Parent: (was: TRAFODION-2917) > Refactor Sequence File Reading to use the new implementation > > > Key: TRAFODION-3171 > URL: https://issues.apache.org/jira/browse/TRAFODION-3171 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > SequenceFileReader is done via JNI/Java earlier. However, the HdfsScan was > traversing the older states in ExHdfsScanTcb work method. This new > implementation should use the current ByteBuffer infrastructure to enable > obsoleting the older implemenation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TRAFODION-3180) At times establishing a JDBC/ODBC connection takes observably long time
[ https://issues.apache.org/jira/browse/TRAFODION-3180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3180: - Description: When it takes time, DCS master status page shows the link between driver and the mxosrvr process is in CONNECTING state. After 30 seconds or a minute, the connection is established. This issue was observed at a customer installation when Trafodion cluster has been up and running for months. (was: When it takes time, DCS master status page shows the link between driver and the mxosrvr process is in CONNECTING state. After 30 seconds or a minute, the connection is established.) > At times establishing a JDBC/ODBC connection takes observably long time > --- > > Key: TRAFODION-3180 > URL: https://issues.apache.org/jira/browse/TRAFODION-3180 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-exe >Affects Versions: any >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > Fix For: 2.4 > > > When it takes time, DCS master status page shows the link between driver and > the mxosrvr process is in CONNECTING state. After 30 seconds or a minute, the > connection is established. This issue was observed at a customer installation > when Trafodion cluster has been up and running for months. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3180) At times establishing a JDBC/ODBC connection takes observably long time
Selvaganesan Govindarajan created TRAFODION-3180: Summary: At times establishing a JDBC/ODBC connection takes observably long time Key: TRAFODION-3180 URL: https://issues.apache.org/jira/browse/TRAFODION-3180 Project: Apache Trafodion Issue Type: Bug Components: sql-exe Affects Versions: any Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan Fix For: 2.4 When it takes time, DCS master status page shows the link between driver and the mxosrvr process is in CONNECTING state. After 30 seconds or a minute, the connection is established. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3171) Refactor Sequence File Reading to use the new implementation
Selvaganesan Govindarajan created TRAFODION-3171: Summary: Refactor Sequence File Reading to use the new implementation Key: TRAFODION-3171 URL: https://issues.apache.org/jira/browse/TRAFODION-3171 Project: Apache Trafodion Issue Type: Sub-task Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan SequenceFileReader is done via JNI/Java earlier. However, the HdfsScan was traversing the older states in ExHdfsScanTcb work method. This new implementation should use the current ByteBuffer infrastructure to enable obsoleting the older implemenation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TRAFODION-2739) RMS semaphore handling need to log the error for easy resolution of the issue
[ https://issues.apache.org/jira/browse/TRAFODION-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-2739. -- Resolution: Fixed https://github.com/apache/trafodion/pull/1231 > 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 >Priority: Major > Fix For: 2.3 > > > 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 (v7.6.3#76005)
[jira] [Commented] (TRAFODION-2739) RMS semaphore handling need to log the error for easy resolution of the issue
[ https://issues.apache.org/jira/browse/TRAFODION-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559005#comment-16559005 ] Selvaganesan Govindarajan commented on TRAFODION-2739: -- This Jira is fixed via the PR [https://github.com/apache/trafodion/pull/1231] > 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 >Priority: Major > Fix For: 2.3 > > > 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 (v7.6.3#76005)
[jira] [Resolved] (TRAFODION-3097) At times the query involving sequence function fail and dumps core
[ https://issues.apache.org/jira/browse/TRAFODION-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan resolved TRAFODION-3097. -- Resolution: Fixed Fix Version/s: 2.3 > At times the query involving sequence function fail and dumps core > -- > > Key: TRAFODION-3097 > URL: https://issues.apache.org/jira/browse/TRAFODION-3097 > Project: Apache Trafodion > Issue Type: Bug > Components: sql-cmp >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > Fix For: 2.3 > > > A core file with the following trace > #0 0x003034632625 in raise () from /lib64/libc.so.6 > #1 0x003034633e05 in abort () from /lib64/libc.so.6 > #2 0x7f71b44191c5 in os::abort(bool) () from > /usr/java/default/jre/lib/amd64/server/libjvm.so > #3 0x7f71b45ba313 in VMError::report_and_die() () > from /usr/java/default/jre/lib/amd64/server/libjvm.so > [004|https://www.esgyn.com/mantis/view.php?id=4] 0x7f71b441e9ef in > JVM_handle_linux_signal () > from /usr/java/default/jre/lib/amd64/server/libjvm.so > [005|https://www.esgyn.com/mantis/view.php?id=5] 0x7f71b4415183 in > signalHandler(int, siginfo*, void*) () > from /usr/java/default/jre/lib/amd64/server/libjvm.so > [006|https://www.esgyn.com/mantis/view.php?id=6] > [007|https://www.esgyn.com/mantis/view.php?id=7] 0x7f71b6006162 in > ex_expr::evalPCode (this=, > pCode32=, atp1=0x7f71a7f34198, atp2=0x7f71a7f4f268, > datalen=, rowLen=0x0) at ../exp/exp_eval.cpp:5111 > [008|https://www.esgyn.com/mantis/view.php?id=8] 0x7f71b72dd468 in > eval (this=0x7f71a7f34390) at ../exp/exp_expr.h:373 > [009|https://www.esgyn.com/mantis/view.php?id=9] > ex_split_bottom_tcb::workUp (this=0x7f71a7f34390) at > ../executor/ex_split_bottom.cpp:1055 > [010|https://www.esgyn.com/mantis/view.php?id=10] 0x7f71b72dda8e in > ex_split_bottom_tcb::work (this=0x7f71a7f34390) > at ../executor/ex_split_bottom.cpp:991 > [011|https://www.esgyn.com/mantis/view.php?id=11] 0x7f71b73ec52e in > ExScheduler::work (this=0x7f71a7f332c8, > prevWaitTime=) at ../executor/ExScheduler.cpp:331 > [012|https://www.esgyn.com/mantis/view.php?id=12] 0x7f71b7235912 in > ExEspFragInstanceDir::work (this=0x7ffd91fb53b0, prevWaitTime=207988) > at ../executor/ex_esp_frag_dir.cpp:766 > [013|https://www.esgyn.com/mantis/view.php?id=13] 0x004070b7 in > runESP(int, char**, GuaReceiveFastStart*) () > [014|https://www.esgyn.com/mantis/view.php?id=14] 0x0040751b in > main () -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TRAFODION-3110) Refactor LOB access to use the new implementation of HdfsClient
[ https://issues.apache.org/jira/browse/TRAFODION-3110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Selvaganesan Govindarajan updated TRAFODION-3110: - Summary: Refactor LOB access to use the new implementation of HdfsClient (was: Make LOB access to use the new implementation of HdfsClient) > Refactor LOB access to use the new implementation of HdfsClient > --- > > Key: TRAFODION-3110 > URL: https://issues.apache.org/jira/browse/TRAFODION-3110 > Project: Apache Trafodion > Issue Type: Sub-task > Components: sql-exe >Reporter: Selvaganesan Govindarajan >Assignee: Selvaganesan Govindarajan >Priority: Major > > By making LOB to use the new implementation of HdfsClient, the use of libHdfs > is avoided in yet another feature. This also simplifies the hdfs access > related code in this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TRAFODION-3110) Make LOB access to use the new implementation of HdfsClient
Selvaganesan Govindarajan created TRAFODION-3110: Summary: Make LOB access to use the new implementation of HdfsClient Key: TRAFODION-3110 URL: https://issues.apache.org/jira/browse/TRAFODION-3110 Project: Apache Trafodion Issue Type: Sub-task Components: sql-exe Reporter: Selvaganesan Govindarajan Assignee: Selvaganesan Govindarajan By making LOB to use the new implementation of HdfsClient, the use of libHdfs is avoided in yet another feature. This also simplifies the hdfs access related code in this feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
