Кластер Glassfish 5 создает JSESSIONID для каждого запроса

Я пытаюсь настроить кластер 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 содержит тег , а приложение развертывается с - availableenabled 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, так и HTTP-балансировщик Apache, оба с одинаковым эффектом. Кроме того, включение закрепленного сеанса на ALB не работает, потому что балансировщик видит другой JSESSIONID и поэтому каждый раз перенаправляет на другой узел.

Я пытаюсь найти способ проверить механизм сеанса, но Я не уверен, какое именно ведение журнала мне нужно включить. Простое увеличение количества журналов javax приводит к нечитаемому журналу.