Нужны ли липкие сеансы при балансировке нагрузки Plone 3.3.5?

Мы столкнулись с проблемой, которая, как мы подозреваем, связана с балансировкой нагрузки. У нас есть 4 внешних клиента ZEO за Apache. Иногда (из журналов) создание нового элемента контента регистрирует ошибку.

2011-04-13T15:39:57 ERROR Zope.SiteErrorLog 1302701997.20.258830910503 https://x/intranet 
/portal_factory/MyType/xxx.2011-04-13.9797548037/xxx_edit
ValueError: Unable to find

Мы подозреваем, что Portal_factory хранит временно созданные элементы в хранилище сеансов клиента ZEO (как мы можем это подтвердить), и это хранилище не используется совместно клиентами ZEO. Когда пользователь нажимает «Сохранить», происходит ошибка проверки, и браузер возвращается к экрану редактирования. Затем этот вид экрана редактирования переходит к другому клиенту ZEO, у которого нет временного «элемента в процессе создания» в его хранилище сеансов.

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

Вот некоторая связанная информация, которая, к сожалению, очень расплывчата:

http://plone.org/documentation/kb/sticky-sessions-and-mod_proxy_balancer


load-balancing apache plone
person Mikko Ohtamaa    schedule 13.04.2011    source источник

Ответы (2)


arrow_upward
5
arrow_downward

В Plone 3 все еще остается некоторый код в логике создания объектов, который действительно использует сеансы. Он предназначен для поддержки интерфейса, похожего на виджет, в котором создание объекта распределяется между несколькими фактическими запросами. Эта поддержка и код отсутствуют в Plone 4.

Этот код в Plone 3 использует доступ к request.SESSION. Хитрость заключается в том, что код использует сеанс только в том случае, если какой-то другой код уже создал его. Никакой код в Plone (даже в Plone 3) не должен создавать сессию в первую очередь, поэтому обычно ее там не будет и она не будет использоваться. Но если какой-либо код на сайте создает сеанс, логика создания объекта также будет использовать его. Это должно объяснить, почему вы не видите проблемы на большинстве сайтов.

Все это особенно сложно, поскольку простой вызов request.SESSION создаст сеанс. Поэтому сценарий content_edit_impl.py в Products.Archetypes использует другой API для доступа к сеансу:

# Avoid implicitly creating a session if one doesn't exists
session = None
sdm = getToolByName(context, 'session_data_manager', None)
if sdm is not None:
    session = sdm.getSessionData(create=0)

create=0 указывает API избегать неявного создания сеанса, если он еще не существует.

Вы можете попытаться найти код, который создает сеанс, настроить код из Archetypes, чтобы удалить часть сеанса, или переместить хранилище сеансов в ZEO и поделиться им со всеми экземплярами Zope. Хотя это не рекомендуется для сайтов с высоким трафиком, в простых сценариях оно должно работать нормально (некоторые подсказки на https://weblion.psu.edu/trac/weblion/wiki/TemporaryStorageInZeo).

person Hanno Schlichting    schedule 13.04.2011

arrow_upward
1
arrow_downward

Ваш диагноз неверен; инструмент portal_factory не имеет состояния и, следовательно, не требует привязки к сеансу.

Ваше сообщение об ошибке также очень расплывчато и выглядит неполным. Вы проверили журнал экземпляра на наличие полных трассировок?

person Martijn Pieters    schedule 13.04.2011