*Scenario 1:* I've created this issue https://issues.apache.org/jira/browse/TRAFODION-1492 I think another fix was made related to *Committed_AS* in *sql/cli/memmonitor.cpp*.
This is a response from Narendra in a previous thread where the issue was fixed to start the trafodion: > > > > *I updated the code: sql/cli/memmonitor.cpp, so that if /proc/meminfo does > not have the ‘Committed_AS’ entry, it will ignore it. Built it and put the > binary: libcli.so on the veracity box (in the $MY_SQROOT/export/lib64 > directory – on all the nodes). Restarted the env and ‘sqlci’ worked fine. > Was able to ‘initialize trafodion’ and create a table.* *Scenario 2:* The *java -version* problem I recall we had only on the other cluster with centos 7, I did't seen it on this one with centos 6.7. But a change I made these days in the latter one is installing oracle *jdk 1.7.0_79* as default one and is where *JAVA_HOME* points to. Before that some nodes had *open-jdk* as default and others didn't have one but just the one installed by path by *ambari* in */usr/jdk64/jdk1.7.0_67* but which was not linked to JAVA_HOME or *java* command by *alternatives*. *Failures is HammerDB:* Attached is the *trafodion.dtm.**log* from a node on which I see a lot of lines like these and I assume is the *transaction conflict* that you mentioned, I see these line on 4 out of 5 nodes: 2015-09-14 12:21:49,413 INFO dtm.HBaseTxClient: useForgotten is true 2015-09-14 12:21:49,414 INFO dtm.HBaseTxClient: forceForgotten is false 2015-09-14 12:21:49,446 INFO dtm.TmAuditTlog: forceControlPoint is false 2015-09-14 12:21:49,446 INFO dtm.TmAuditTlog: useAutoFlush is false 2015-09-14 12:21:49,447 INFO dtm.TmAuditTlog: ageCommitted is false 2015-09-14 12:21:49,447 INFO dtm.TmAuditTlog: disableBlockCache is false 2015-09-14 12:21:52,229 INFO dtm.HBaseAuditControlPoint: disableBlockCache is false 2015-09-14 12:21:52,233 INFO dtm.HBaseAuditControlPoint: useAutoFlush is false 2015-09-14 12:42:57,346 INFO dtm.HBaseTxClient: Exit RET_HASCONFLICT prepareCommit, txid: 17179989222 2015-09-14 12:43:46,102 INFO dtm.HBaseTxClient: Exit RET_HASCONFLICT prepareCommit, txid: 17179989277 2015-09-14 12:44:11,598 INFO dtm.HBaseTxClient: Exit RET_HASCONFLICT prepareCommit, txid: 17179989309 What *transaction conflict* means in this case? On Wed, Sep 16, 2015 at 2:43 AM, Selva Govindarajan < [email protected]> wrote: > Hi Radu, > > Thanks for using Trafodion. With the help from Suresh, we looked at the > core > files in your cluster. We believe that there are two scenarios that is > causing the Trafodion processes to dump core. > > Scenario 1: > Core dumped by tdm_arkesp processes. Trafodion engine has assumed the > entity > /proc/meminfo/Committed_AS is available in all flavors of linux. The > absence of this entity is not handled correctly by the trafodion tdm_arkesp > process and hence it dumped core. Please file a JIRA using this link > https://issues.apache.org/jira/secure/CreateIssue!default.jspa and choose > "Apache Trafodion" as the project to report a bug against. > > Scenario 2: > Core dumped by tdm_udrserv processes. From our analysis, this problem > happened when the process attempted to create the JVM instance > programmatically. Few days earlier, we have observed similar issue in your > cluster when java -version command was attempted. But, java -version or > $JAVA_HOME/bin/java -version works fine now. > Was there any change made to the cluster recently to avoid the problem with > java -version command? > > You can please delete all the core files in sql/scripts directory and issue > the command to invoke SPJ and check if it still dumps core. We can look at > the core file if it happens again. Your solution to the java -version > command would be helpful. > > For the failures with HammerDB, can you please send us the exact error > message returned by the Trafodion engine to the application. This might > help > us to narrow down the cause. You can also look at > $MY_SQROOT/logs/trafodion.dtm.log to check if any transaction conflict is > causing this error. > > Selva > -----Original Message----- > From: Radu Marias [mailto:[email protected]] > Sent: Tuesday, September 15, 2015 9:09 AM > To: dev <[email protected]> > Subject: Re: odbc and/or hammerdb logs > > Also noticed there are several core. files from today in > */home/trafodion/trafodion-20150828_0830/sql/scripts*. If needed please > provide a gmail address so I can share them via gdrive. > > On Tue, Sep 15, 2015 at 6:29 PM, Radu Marias <[email protected]> wrote: > > > Hi, > > > > I'm running HammerDB over trafodion and when running virtual users > > sometimes I get errors like this in hammerdb logs: > > *Vuser 1:Failed to execute payment* > > > > *Vuser 1:Failed to execute new order* > > > > I'm using unixODBC and I tried to add these line in */etc/odbc.ini* > > but the trace file is not created. > > *[ODBC]* > > *Trace = 1* > > *TraceFile = /var/log/odbc_tracefile.log* > > > > Also tried with *Trace = yes* and *Trace = on*, I've found multiple > > references for both. > > > > How can I see more logs to debug the issue? Can I enable logs for all > > queries in trafodion? > > > > -- > > And in the end, it's not the years in your life that count. It's the > > life in your years. > > > > > > -- > And in the end, it's not the years in your life that count. It's the life > in > your years. > -- And in the end, it's not the years in your life that count. It's the life in your years.
trafodion.dtm.log.tar.gz
Description: GNU Zip compressed data
