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

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