сервера WebLogic jsessionid

Я запускаю Weblogic 10.3 локально и имею вопрос о sessionId, который он генерирует. Когда я печатаю сеанс.getId () я вижу что-то похожее на это:

BBp9TAACMTglQ2TDFAKR4tpyXg73LZDQj2ptt9x8htg1twy122aa!869187422!1308677666322

что это за восклицательные знаки и что за ними следует, в частности вторая пара:!1308677666322 ? Похоже, что иногда сервер добавляет его, а иногда нет. Я считаю, что WebLogic добавляет это если я использую тот же браузер для входа в свое приложение во второй раз. Это как-то связано с cookie?

2 ответов


глядя на некоторые случайно сгенерированные Weblogic JSessionIDs из моего собственного приложения

BrYx4hyPZ4VSP9Wo4eU0OrqmhXMLFONbRHnpLFwRKZ9MSaf6wvYj!-314662473

и

BrYiFED29itaC4EBpWYM8RKVQQauHkvnTsA2OAKUPZXVc9oUD5fB!-784323496.

теперь, если вы заметили часть ID сеанса после первого ! я.е 314662473 и 784323496.

это число является уникальный идентификатор что Weblogic дает запущенной JVM т. е. запущенному серверу Weblogic.

если в вашем приложении более одного сервера, Weblogic знает, как направьте сеанс обратно на правильный сервер, используя этот 9-значный номер JVM, который является частью идентификатора сеанса.

каждый раз, когда вы перезапускаете сервер weblogic, он будет генерировать новый идентификатор JVM и использовать его до тех пор, пока этот сервер weblogic работает. Таким образом, любые обращения к этому серверу будут иметь тот же идентификатор в конце идентификатора сеанса.

на формат ID сеанса есть:

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!SECONDARY_JVM_HASH!CREATION_TIME

поэтому, если первичный не доступен, он попытается перейти на вторичный и если вы включили репликацию сеанса - тогда данные сеанса могут быть восстановлены. Если вы используете только один сервер на локальном, то формат просто

JSESSIONID=SESSION_ID!PRIMARY_JVMID_HASH!CREATION_TIME

по несколько раз не отображается, я видел, что обычно браузер зависит от того, отображается ли sessionid в адресной строке или нет


WebLogic Server использует эти идентификаторы для поддержания сродства сеанса HTTP в модели репликации кластера WebLogic в памяти.

для тех веб-приложений с включенной репликацией сеанса HTTP (в weblogic.XML-дескриптор развертывания и отключен по умолчанию) WebLogic сохранит первичную и резервную копию вашего HTTP-сеанса с кластером.

чтобы избежать накладных расходов кластера, подключаемый модуль WebLogic Proxy (развернутый на уровне веб-уровня) анализирует cookie сеанса и перенаправляет каждый запрос на WLS, на котором размещена ваша основная копия. В случае сбоя или накладных расходов управляемого сервера, на котором размещен основной сеанс, подключаемый модуль Прокси перенаправляет запрос на экземпляр, на котором находится сеанс HTTP.

плагин прокси будет отслеживать динамический список всех членов кластера WebLogic в виде пар (JVM IDs / IP:ports) для перенаправления каждого запроса соответствующим образом.

Если ваше приложение не включает функцию репликации в памяти, ваш cookie будет включите только идентификатор JVM, где живет ваш http Sesion (первичная и уникальная копия).