Glassfish 5 集群在每个请求上创建 JSESSIONID

Glassfish 5 集群在每个请求上创建 JSESSIONID

我正在尝试按照官方 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 版本,问题就消失了。

相关内容