7省BUG分析一

 

1.1.1    1：2007-8-1出现超时

中心反馈落地方业务超时，业务完成周期超过集团公司的规定时间。

 

原因分析：日志里反复提示连接 DOMAIN 失败，对 TUXEDO 的日志跟踪分析后，湖南的超时分析后发现是因为一级 BOSS 和彩铃公用一个 DOMAIN  引起的，日志里总是返回调不到服务， Unable to obtain remote domain id (WEBTTDOM41) information 等待超时，后来将 DOMAIN 分开后问题解决。观察了一个星期后没有再次出现超时。

 

具体解决方法：

在 DBB 文件中新建一个独立的 DOMAIN

TUXDOM GWGRP=GRPDOM

        TYPE=TDOMAIN

        DOMAINID="TUXDOM"

        BLOCKTIME=240  

        MAXDATALEN=204800 

        MAXRDOM=89

        CONNECTION_POLICY=ON_DEMAND

        DMTLOGDEV="/gboss/tuxapp/etc/DLOG"

        DMTLOGNAME="DLOG"

       

TUXDOMCL GWGRP=GRPDOMCL

        TYPE=TDOMAIN

        DOMAINID="TUXDOMCL"

        BLOCKTIME=240

        MAXDATALEN=204800

        MAXRDOM=89

        CONNECTION_POLICY=ON_DEMAND

        DMTLOGDEV="/gboss/tuxapp/etc/CLDLOG"

        DMTLOGNAME="DLOG"

 

如上面那样，加一个独立的 DOMAIN ，同时也需要在 UBBMW32 加一个组。

# TUXEDO 系统管理组 GRPNO = 100 开始，间隔为 10

GRPWSL

        LMID=gboss     GRPNO=100        OPENINFO=NONE

GRPJSL

        LMID=gboss     GRPNO=110        OPENINFO=NONE

GRPDOM

                                LMID=gboss     GRPNO=120 OPENINFO=NONE

GRPDOMCL

                                LMID=gboss     GRPNO=130 OPENINFO=NONE

 

目前仍然有部分省还是配置在一起的，比如云南等省，我检查后发现没有新加 DOMAIN ，还是公用同一个 DOMAIN 。建议现场可以把 DOMAIN 分开。

*DM_LOCAL_DOMAINS

TUXDOM GWGRP=GRPDOM

        TYPE=TDOMAIN

        DOMAINID="TUXDOM"

        BLOCKTIME=240  

        MAXDATALEN=204800 

        MAXRDOM=89

        CONNECTION_POLICY=ON_STARTUP

       DMTLOGDEV="/gboss/tuxapp/etc/DLOG"

        DMTLOGNAME="DLOG"

 

 

 

1.2            安徽超时

1.2.1    1：2007-8-13超时

新疆出现超时，检查后发现超时的原因为数据库问题，下面的分析原因

错误原因：调服务失败，错误日志为

[DEBUG] [2007-08-13 17:06:44] -=> [HttpSender] Http 超时时间 :180000
[ERROR] [2007-08-13 17:06:45] -=> 调用 tuxedo 服务返回系统级的错误
TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0
        at weblogic.wtc.jatmi.dsession.tpgetrply(dsession.java:3057)
        at weblogic.wtc.jatmi.dsession.tpcall(dsession.java:3219)
        at weblogic.wtc.gwt.TuxedoConnection.tpcall(TuxedoConnection.java:1361)
        at com.linkage.uip.sender.TuxedoServiceCaller.callTuxedoService(Unknown Source)
        at com.linkage.uip.sender.TuxedoServiceCaller.sendRequestData(Unknown Source)
        at com.linkage.iboss.sender.IBossTuxSvcCaller.sendRequestData(Unknown Source)
        at com.linkage.iboss.sender.IBossCommonSender.sendRequestData(Unknown Source)
        at com.linkage.uip.processor.BusiInvokeCMD.execute(Unknown Source)
        at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
        at com.linkage.uip.processor.DefaultChain.execute(Unknown Source)
        at com.linkage.uip.processor.LoadSubSystemUnitCMD.execute(Unknown Source)
        at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
        at com.linkage.uip.processor.DefaultChain.execute(Unknown Source)
        at org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
        at com.linkage.uip.processor.DefaultChain.execute(Unknown Source)
        at com.linkage.uip.processor.CommonDataProc.process(Unknown Source)
        at com.linkage.uip.receiver.HTTPDataReceiver.doPost(Unknown Source)

 

那么这样的错误可以排除 WEBLOGIC 的问题，肯定和 TUXEDO 有关，仔细检查 TUXEDO 日志，在发生错误的时间段，数据库有异常信息：

171104.boss1t2!TMS_ORA.20967.1.0: gtrid x0 x469b9f5c x44aba8:   CMDTUX_CAT:443: ERROR: tms_timeout group GRPITFUIF xa_abort returned
 XAER_RMERR
171104.boss1t2!TMS_ORA.20966.1.0: gtrid x0 x469b9f5c x44abaa:   CMDTUX_CAT:443: ERROR: tms_timeout group GRPITFUIF xa_abort returned
 XAER_RMERR
171104.boss1t2!tcscrm1l1server.331.1.0: LIBTUX_CAT:1397: WARN: tpreturn transaction processing failure
171109.boss1t2!TMS_ORA.20965.1.0: gtrid x0 x469b9f5c x44abac:   CMDTUX_CAT:443: ERROR: tms_timeout group GRPITFUIF xa_abort returned
 XAER_RMERR
171109.boss1t2!tcscrm1l1server.20936.1.0: LIBTUX_CAT:1397: WARN: tpreturn transaction processing failure
171109.boss1t2!TMS_ORA.20967.1.0: gtrid x0 x469b9f5c x44abab:   CMDTUX_CAT:443: ERROR: tms_timeout group GRPITFUIF xa_abort returned
 XAER_RMERR

 

13 号当天 17 点左右数据库有非正常信息。

 

 

 

1.3            北京超时

 

1.3.1    1：2007-8-16，超时

业务超时， 1000 多笔，原因：硬盘出故障，现在已经恢复。

 

现象：中心反馈落地方业务超时，业务完成周期超过集团公司的规定时间。

 

陕西的超时是落地方调不到服务（具体那次的我不清楚了），检查数据库的时候发现死锁，查后发现数据库连接池已经满了，不够用，后来检查程序后发现是程序的 BUG ，没有及时释放数据库连接对象，这个错误以前云南就出现了，单子也早提了，单子号是： YJBOSS-YNYD-YZ-BUG-20070618-001 但是可能没有及时更新。

     TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0 这样的异常，还有一个原因就是订购关系进行批量的时候，数据会突然猛增，服务在被调的时候来不及处理，等待超时，这样的异常目前都是将总控重新启动。或者将服务多调几个。

 

 

1.4            湖北超时

1.4.1    2007-8-12，超时

现象：中心反馈落地方业务超时，业务完成周期超过集团公司的规定时间。

原因分析：因为当天晚上正好青海主机搬迁，所以就没有继续查，没有查出具体原因。

 

 

1.5            吉林超时

1.5.1    1：2007-8-1，超时

现象描述：中心反馈落地方业务超时，业务完成周期超过集团公司的规定时间。

 

天津 8 月 1 号的超时原因：

日志显示为：

dMaxTime) of "600" seconds.>

<2007-8-1 00 时 20 分 13 秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '7' for queue: 'weblogic.kernel.Default' has

 been busy for "878" seconds working on the request "Http Request: /XMLReceiver", which is more than the configured time (StuckThrea

dMaxTime) of "600" seconds.>

<2007-8-1 00 时 20 分 13 秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '8' for queue: 'weblogic.kernel.Default' has

 been busy for "841" seconds working on the request "Http Request: /XMLReceiver", which is more than the configured time (StuckThrea

dMaxTime) of "600" seconds.>

<2007-8-1 00 时 20 分 13 秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '9' for queue: 'weblogic.kernel.Default' has

 been busy for "951" seconds working on the request "Http Request: /XMLReceiver", which is more than the configured time (StuckThrea

dMaxTime) of "600" seconds.>

<2007-8-1 00 时 20 分 13 秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '11' for queue: 'weblogic.kernel.Default' ha

s been busy for "881" seconds working on the request "Http Request: /XMLReceiver", which is more than the configured time (StuckThre

adMaxTime) of "600" seconds.>

<2007-8-1 00 时 20 分 13 秒 GMT+08:00> <Error> <WebLogicServer> <BEA-000337> <ExecuteThread: '14' for queue: 'weblogic.kernel.Default' ha

s been busy for "752" seconds working on the request "Http Request: /XMLReceiver", which is more than the configured time (StuckThre

adMaxTime) of "600" seconds.>

 

 

 

   

目前超时的现象没还是比较严重的，尤其是最近几个月，由于最近上线的集团业务特别多， ADC ， MAS ， GATEWAY ， MUSC ，手机邮箱等，这些都是建的独立的 DOMAIN ，非常耗资源，尤其是有的数据都是批量，但是各省的主机资源没有及时的调整，上次云南的机器内存都用到 99% 了，后来及时增加了资源才没有出现严重的故障，还有就是现场在做维护的时候，部分配置不合理，甚至是错的， TUXEDO 很多都是 TAR 来 TAR 去的，没有多服务进行一些优化。