1. 概述

11月15日上午8点半开始tuxedo ULOG日志开始频繁的抛出一个关于GWTDOMAIN的告警，并伴随部分服务调用失败，下午4点左右大面积WTC调用tuxedo域服务失败，重启整个tuxedo系统，故障恢复。10月份也出现过一次这样的情况。

2. 问题分析

15日上午8点半开始报如下错误：

持续时间为：8:32-8:34，之后没有报上面的错误，直到14:31有开始频繁的报错，此次报错一直持续到15:59重启系统，在这两个阶段的报错中，调用失败的远程域主要有：(其中前三个域调用失败比较多)

远程域通过本地域的GWTDOMAIN调用本地服务失败，错误号为402018，在metalink上查找这个错误没有任何消息；但查到gwerrno(402017)错误表示调用的service不存在，GWTDOMAIN会抛出上面这个错误；如果本地的server的队列满了，会抛出错误号为gwerrno(402019)的错误，我们碰到的不是这两个错误，于是开SR，800工程师给我们的解释如下：

GWTDOMAIN在处理请求是内部有一个context的资源，如果这个资源被占满了，那么就会抛出gwerrno(402018)错误，同时请求也不能被转发到相应的server进行处理。导致这个资源被占满的原因通常是因为本地的服务积压，只要正在处理还没有返回的请求都会占用这个资源，如果已经返回了就不会占用了。

通过oracle论坛找到这个GWTDOMAIN的context资源上限是10000，但根据管理员反映当时查看pq队列最多也就有几百的排队，但到了下午排队也消失了，如果按照800的解释正在处理的请求也占用这个context资源，那么理论上达到这个上限也有可能。但是，和这个tuxedo domain同样的配置、负载更高的另外一个域却没有出现过这样的情况。

3. 问题建议

1) 注意监控server队列排队情况，并使用psr查看各server的运行状态，是否存在服务积压。特别注意在本次出现问题时调用失败比较多的三个域wtc6_pay2_230  wtc6_pay1_230 wtc6_abm2_230所调用的服务以及它们的队列

2) 再次出现同样问题时，可尝试重启与域相关的3个进程DMADM GWADM GWTDOMAIN，注意启动的时候顺序启动上面三个进程，停止的时候倒序停止，如果不起作用则需要重启整个域

3) 增加一组新的网关进程组，有两个网关进程分担所有远程域的服务请求。但要注意如果单单增加一组网关，而远端的网关不做对应的修改，这个增加没有意义；需要把远端的网关配置成负载均衡的模式才有意义，需要把所有的远端的网关上的服务配置成负载均衡模式，否则有可能某些处理比较慢的请求有可能会配置到一个网关上，这样就不能解决问题了。或者根据业务划分也可以。

4. 远程域重名问题

在ULOG中发现大量如下信息：

上面信息是由于存在重名的远程域连接本地域时，一个域会把另一个域的连接踢掉，被踢掉的域会根据当前域配置里的RETRY_INTERVAL=10参数每隔10秒重新连接，这样又把之前的域连接踢掉，这样反复重连对服务调用的性能会造成一定的影响，同时也不便于域管理。

可通过在本地域设置GW_VALIDATE_HOST=YES环境变量，验证发起连接请求的远程域IP，如果该IP没有在域配置文件中指定，则禁止连接。设置完环境变量后，会在下次tuxedo启动的时候打出LIBGWT_CAT:1612:INFO: Validate host feature is enabled by xxdom，出现上述信息表示环境变量设置成功。

不过这种方式还是存在弊端的，如果这两个同名的远程域是在同一台主机上并共用一个IP时，上面设置的参数则不会起作用。所以建议我们的管理员还是根据日志中报的同名域名称，找到它们并重新赋予新的域名称。