系统还是会经常（时不时地）超时

jishuang · 发表于 2019-4-2 13:34:54

可以修改一下看看是不是这个问题

江苏院-吴昊 · 发表于 2019-4-2 14:01:53

本帖最后由江苏院-吴昊于 2019-4-2 14:04 编辑

jishuang 发表于 2019-4-2 13:34
可以修改一下看看是不是这个问题

1.如果其他人不修改也没有问题，这是为什么呢？
2.还有这个JUSTEP002012 对应的中文在哪看？我反编译了ui-core.jar，发现UIUitls里的逻辑，就是发现没有bsessionid导致记录了告警日志，提示“没有bsessionid，可能会报错”

3.context.j是哪里发出请求的？后面的参数都是拼接上去的，我想看看那里的逻辑，看看如果第一次没有获取到，有没有机会再去获取下。浏览器cookie里的bsessionid一直都在的

jishuang · 发表于 2019-4-2 14:34:35

1.具体什么问题要具体去跟，不同环境原因不一定一样，集群下有问题的可能性打，但UI转调肯定没问题
2.http://bbs.wex5.com/forum.php?mod=viewthread&tid=53936
3.代码是不开源的

江苏院-吴昊 · 发表于 2019-4-2 15:32:59

本帖最后由江苏院-吴昊于 2019-4-2 15:37 编辑

jishuang 发表于 2019-4-2 14:34
1.具体什么问题要具体去跟，不同环境原因不一定一样，集群下有问题的可能性打，但UI转调肯定没问题
2.http: ...

我大致找到了一些原因，主要还是跟cookie有关。
我做了几个试验，浏览器为chrome

（1）不使用UI转调的情况，即directConnectBiz=true
浏览器cookie主要有：
1. JSESSIONID path: /x5
2. JSESSIONID path: /BusinessServer
3. JSESSIONID path: /BusinessServer/
4. bsessionid path: /

1是UIServer的tomcat sessionid
2和3 都是 BusinessServer 的sessionid，只是path不同，但值是一样的（也有可能不一样，我推测的）
4是平台的bsessionid

试验方法：
如果只将bsessionid删除，是不会超时的，只不过justep.ui.log里会有告警日志：“bsessionid不存在，可能会出错”；
如果不删除bsessionid，删除的是2或者3（且2和3的值相同），即删除其中一个BusinessServer的会话ID，也不会超时，justep.ui.log也不会有告警日志。
如果全部删除2和3，会超时！justep.ui.log也不会有告警日志。

而我们的生产环境里justep.ui.log没有告警日志，是因为cookie里BusinessServer sessionid的问题，而不是bsessionid的问题。如果是bsessionid的问题，justep.ui.log肯定会有告警。此外我在nginx的access_log里，查找了context.j的日志，没有发现不带bsessionid的请求！

那在生产环境下，会是什么原因导致超时，我推测是2和3两个值不一样。这两个值都会传递到BusinessServer，BusinessServer取了其中之一和平台的bsessionid比较，如果取到了正确的，则不会超时，如果恰好取到了另外一个，则会报超时。仔细观察我一楼的图片，jsessionid: 后是有两个JSESSIONID，我怀疑是2和3的值不同。

（2）使用UI转调的情况，即directConnectBiz=false

浏览器cookie主要有：
1. JSESSIONID path: /x5

2. bsessionid path: /

可以看出没有businessServer的jsessionid了，因为是用UIServer进行转调了。

试验方法：
如果直接从cookie中删除bsessionid，那么系统会超时，且justep.ui.log中会有告警日志。

这也是用UI转调的方式比 biz直连的方式稳定很多的原因。

综上，平台为什么会设置（什么原因导致产生）两个BusinessServer的jsessionid，path却不同，一个是/BusinessServer，另一个是/BusinessServer/。如果两个不一样，出问题的概率会大大增加

江苏院-吴昊 · 发表于 2019-4-2 15:34:34

UI转调的效率是否会比较低？低多少？

jishuang · 发表于 2019-4-2 16:11:42

1.超时的时候跟踪network中请求看看具体哪个请求中到的jsessionid变了
2.这个差别有限，可以忽略不计

江苏院-吴昊 · 发表于 2019-4-2 16:20:00

jishuang 发表于 2019-4-2 16:11
1.超时的时候跟踪network中请求看看具体哪个请求中到的jsessionid变了
2.这个差别有限，可以忽略不计 ...

1. 不是要跟踪哪个变了，这个是不能稳定复现的现象，无法跟踪。不是我们业务逻辑去修改的。

关键是设置一个BusinessServer的cookie就对了

jishuang · 发表于 2019-4-2 17:01:22

设置两个BusinessServer肯定是有原因的，是兼容不同的应用服务的

知道不是业务逻辑去修改了，是需要跟踪看具体到哪个请求看看具体的堆栈信息

江苏院-吴昊 · 发表于 2019-4-2 18:39:23

jishuang 发表于 2019-4-2 17:01
设置两个BusinessServer肯定是有原因的，是兼容不同的应用服务的

知道不是业务逻辑去修改了，是需要跟踪看 ...

是特意设置的啊？只要不是bug就好

jishuang · 发表于 2019-4-3 08:41:18

设置肯定是有原因的

		自动登录	找回密码
密码			注册

[结贴] 系统还是会经常（时不时地）超时