tuxedo:WS Handler has been shutdown_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
2
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3789 | 回复: 1   主题: tuxedo:WS Handler has been shutdown        下一篇 
lujixiang
注册用户
等级:新兵
经验:66
发帖:2
精华:0
注册:2014-3-13
状态:离线
发送短消息息给lujixiang 加好友    发送短消息息给lujixiang 发消息
发表于: IP:您无权察看 2014-10-11 11:17:18 | [全部帖] [楼主帖] 楼主

客户端调服务端时,程序不稳定,经常会出现调用错误。

ULOG日志

170612.ivmcgkf!?proc.19332.2.0: LIBWSC_CAT:1477: INFO: WS Handler has been shutdown
170612.ivmcgkf!?proc.19332.2.0: LIBWSC_CAT:1085: ERROR: Unable to get reply to unsolicited message request
170617.ivmcgkf!?proc.19300.2.0: 02-26-2013: Tuxedo Version 10.3.0.0, 32-bit
170617.ivmcgkf!?proc.19300.2.0: LIBWSC_CAT:1477: INFO: WS Handler has been shutdown
170617.ivmcgkf!?proc.19300.2.0: LIBWSC_CAT:1085: ERROR: Unable to get reply to unsolicited message request
170617.ivmcgkf!?proc.24300.2.0: 02-26-2013: Tuxedo Version 10.3.0.0, 32-bit
170617.ivmcgkf!?proc.24300.2.0: LIBWSC_CAT:1477: INFO: WS Handler has been shutdown
170617.ivmcgkf!?proc.24300.2.0: LIBWSC_CAT:1085: ERROR: Unable to get reply to unsolicited message request
173256.ivmcgkf!?proc.19329.1.0: LIBWSC_CAT:1037: ERROR: Network message receive failure
173256.ivmcgkf!?proc.19329.2.0: LIBWSC_CAT:1037: ERROR: Network message receive failure
173256.ivmcgkf!?proc.19329.2.0: LIBWSC_CAT:1085: ERROR: Unable to get reply to unsolicited message request
173256.ivmcgkf!?proc.19329.2.0: LIBWSC_CAT:1037: ERROR: Network message receive failure
173256.ivmcgkf!?proc.19329.2.0: LIBWSC_CAT:1085: ERROR: Unable to get reply to unsolicited message request


重启服务就会好,客户端是动态库,哪位高手知道是什么问题,帮忙解答下,万分感谢!

--转自 北京联动北方科技有限公司




赞(0)    操作        顶端 
koei123
注册用户
等级:大校
经验:4196
发帖:16
精华:0
注册:2011-7-21
状态:离线
发送短消息息给koei123 加好友    发送短消息息给koei123 发消息
发表于: IP:您无权察看 2014-10-21 18:42:09 | [全部帖] [楼主帖] 2  楼

Tuxedo远程客户端链接时,先访问WSL;然后WSL分配一个WSH负责这个客户端,并把WSH的监听端口号发给它;

接着,WS客户端离开WSL,再向WSH监听发起建链请求,成功的话获得内部识别会话ID号,并在后续交互中始终带着这个身份证;

如果某个时候,WSH收到的客户端报文中,包含的身份证ID和本身自己存储印证的不一致,就说明有人走错门了或者冒充了,然后WSH就会产生这种基于安全的自我保护动作;

打个比方:地址从A浮动到B后,客户端的报文会被导向到B,但B上WSH的内部ID号是B的,WS客户端报文内部带的却是A的,自然就不行了;如果是重新建链来过,自然两边都换成新ID了,就没有问题;
楼主的这个问题更单纯,一般是握好手的WSH已经退出了,所以也不用整个重启服务端,估计重启下WSL就能OK掉。



赞(0)    操作        顶端 
总帖数
2
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论