![Glassfish 5 集群在每个请求上创建 JSESSIONID](https://linux22.com/image/751079/Glassfish%205%20%E9%9B%86%E7%BE%A4%E5%9C%A8%E6%AF%8F%E4%B8%AA%E8%AF%B7%E6%B1%82%E4%B8%8A%E5%88%9B%E5%BB%BA%20JSESSIONID.png)
我正在尝试按照官方 HA 指南配置 Glassfish 集群。
该应用程序是一个标准的 JSF 应用程序(带有 Primefaces)。起初我以为问题与 JSF 本身有关,但随着我深入了解此事,我意识到问题很可能出在集群配置上。
事实上,如果集群只包含一个节点,一切都会正常。一旦我添加另一个节点,尽管日志消息显示没有发生任何错误,但每个请求都会创建一个新的 JSESSIONID。
这是确认实例正确相互看到的日志:
实例1:
[2020-04-16T09:11:43.201+0000] [glassfish 5.1] [INFO] [view.window.view.change] [ShoalLogger] [tid: _ThreadID=37 _ThreadName=GMS ViewWindowThread Group-my-cluster] [timeMillis: 1587028303201] [levelValue: 800] [[
GMS1092: GMS View Change Received for group: my-cluster : Members in view for ADD_EVENT(before change analysis) are :
1: MemberId: instance1, MemberType: CORE, Address: 10.0.20.9:9090:230.30.1.1:9090:my-cluster:instance1
2: MemberId: instance2, MemberType: CORE, Address: 10.0.10.14:9090:230.30.1.1:9090:my-cluster:instance2
3: MemberId: server, MemberType: SPECTATOR, Address: 10.0.10.4:9090:230.30.1.1:9090:my-cluster:server
]]
实例 2
[2020-04-16T09:11:43.136+0000] [glassfish 5.1] [INFO] [view.window.view.change] [ShoalLogger] [tid: _ThreadID=45 _ThreadName=GMS ViewWindowThread Group-my-cluster] [timeMillis: 1
587028303136] [levelValue: 800] [[
GMS1092: GMS View Change Received for group: my-cluster : Members in view for ADD_EVENT(before change analysis) are :
1: MemberId: instance1, MemberType: CORE, Address: 10.0.20.9:9090:230.30.1.1:9090:my-cluster:instance1
2: MemberId: instance2, MemberType: CORE, Address: 10.0.10.14:9090:230.30.1.1:9090:my-cluster:instance2
3: MemberId: server, MemberType: SPECTATOR, Address: 10.0.10.4:9090:230.30.1.1:9090:my-cluster:server
]]
另外从 DAS 日志来看,总体情况良好:
[2020-04-16T12:52:59.360+0000] [glassfish 5.1] [FINER] [] [ShoalLogger] [tid: _ThreadID=55 _ThreadName=GMS InDoubtPeerDetector Thread for Group-my-cluster] [timeMillis: 1587041579360] [levelValue: 400] [CLASSNAME: com.sun.enterprise.mgmt.HealthMonitor$InDoubtPeerDetector] [METHODNAME: processCacheUpdate] [[
processCacheUpdate : instance2 's state is aliveandready]]
......
[2020-04-16T12:52:59.359+0000] [glassfish 5.1] [FINER] [] [ShoalLogger] [tid: _ThreadID=55 _ThreadName=GMS InDoubtPeerDetector Thread for Group-my-cluster] [timeMillis: 1587041579359] [levelValue: 400] [CLASSNAME: com.sun.enterprise.mgmt.HealthMonitor$InDoubtPeerDetector] [METHODNAME: processCacheUpdate] [[
processCacheUpdate : instance1 's state is aliveandready]]
web.xml 包含<distributable/>
标签,应用程序已部署--availabilityenabled true
,我已将其添加<property name="relaxCacheVersionSemantics" value="true"/>
到 glassfish-web.xml 中。
最后,cookie 也设置正确,我正在浏览器检查器中验证 cookie 的正确性。
<cookie-properties>
<property name="cookieDomain" value=".mydomain.com" />
<property name="cookiePath" value="/myapp" />
</cookie-properties>
我花了将近一周的时间试图了解发生了什么,但毫无进展。我读过的所有文章和博客都报告了相同的解决步骤,我已经应用了这些步骤。我还将日志记录增加到最高级别,但没有发现任何错误或类似情况。
一个关键因素是集群位于 Amazon AWS 上,而且因为我不确定是否完全支持多播,所以我使用 将集群广播切换到 TCP GMS_DISCOVERY_LIST
。但显然,由于实例彼此可见,因此此设置有效。
我尝试过 Elastic Load Balancer 和 Apache HTTP 负载均衡器,效果都一样。此外,在 ALB 上启用粘性会话不起作用,因为均衡器JSESSIONID
每次都会看到不同的节点,因此会重定向到不同的节点。
我正在尝试找到一种方法来检查会话机制,但我不确定必须启用哪些特定日志记录。简单地增加 javax 日志记录会导致无法读取日志。
答案1
唯一的解决方案非常激烈:删除 glassfish 并安装最新的 Payara Server 版本,问题就消失了。