Практическое значение параметра concurrent-request-timeout или параметров, позволяющих избежать одновременного доступа к исключению диалога

Question

В Справочном руководстве по шву можно найти этот абзац:

Мы можем установить разумное значение по умолчанию для времени ожидания одновременного запроса (в мс) в файле component.xml:

<core:manager concurrent-request-timeout="500" />

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

В нашем приложении у нас есть комбинация запросов ajax на уровне страниц (инициируемых различными пользовательскими действиями), некоторой логики уведомлений о глобальном опросе (часть заголовка, включенной на каждой странице) и обычных ссылок, которые вызывают действия и / или переходят к другим страницы.

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

Немного изучив варианты, мы в конечном итоге увеличили это значение до нескольких секунд (мы обсуждаем, стоит ли увеличивать его до 10 с), поскольку ни одно из рекомендуемых решений, казалось, не могло полностью решить нашу проблему (даже форсировать глобальное изменение). Очередь для всех запросов AJAX по-прежнему оставляла бы нас открытыми для пользователя, который решил щелкнуть ссылку прямо во время одного из наших опросов). И мы бы предпочли, чтобы пользователи подождали секунду или две вместо того, чтобы получить страницу с ошибкой только потому, что они нажали на ссылку в неподходящий момент.

А теперь вопрос: есть ли что-то очевидное, что мы упускаем (например, способ обеспечить одновременный доступ к разговорам и позаботиться о необходимой блокировке, например:)? Как люди решают эту проблему (запросы ajax, смешанные с пользовательским взаимодействием) в шве? Отключение всех ссылок на странице во время выполнения ajax-запросов (как предлагает одна страница блога) на самом деле не является жизнеспособным вариантом.

Любые другие предложения?

ТИА, Андрей

Answer 1

Мы используем 60000 или 120000 (1-2 минуты). Тайм-аут параллельного запроса разработан, чтобы избежать тупиков. Исторически у нас гораздо больше проблем с таймаутами, чем с тупиками. Лучше всего использовать очередь на стороне клиента (<a4j:ajaxQueue> если вы используете RichFaces) для максимально возможной сериализации и удаления повторяющихся запросов, то установите таймаут достаточно высоким, чтобы избежать оставшихся проблем.

Есть много серьезных проблем, связанных с одновременным истечением времени ожидания запроса Seam:

• Проблема заключается в том, что последний запрос получает исключение ConcurrentRequestTimeoutException. Если пользователь дважды щелкает или перезагружает страницу, имеет значение только последний запрос - почему он должен получить ошибку?
• Обычно исключение ConcurrentRequestTimeoutException подавляется, и только вторичные исключения NullPointerException и @In Отказы инъекций показаны, что затрудняет отладку.
• Seam 2.2.1 имеет серьезную проблему, когда транзакции, ThreadLocals и блокировки могут просочиться после истечения времени ожидания, особенно при использовании с <spring:spring-transaction/>, смотреть на SeamPhaseListener.afterRestoreView: нет никаких finally блок для очистки после restoreConversation терпит неудачу!

На мой взгляд, в этом дизайне есть много недостатков, поэтому лучше использовать гораздо более длительное время ожидания и стараться избегать проблем.

Answer 2

Это то, что у нас есть, и оно прекрасно работает для нас:

<core:manager concurrent-request-timeout="5000"
    conversation-timeout="120000" conversation-id-parameter="cid"
    parent-conversation-id-parameter="pid" />

Answer 3

Мы также используем намного более высокое значение для параллельного времени ожидания запроса.

По крайней мере, для дублированных событий вы можете использовать настройки в компонентах a4j, чтобы отфильтровать и задержать их с помощью eventsQueue, requestDelay и ignoreDupResponses = ”true”.

(Последний пункт http://docs.jboss.org/seam/2.0.1.GA/reference/en/html/conversations.html)

Answer 4

Можете ли вы проанализировать, какие типы запросов занимают много времени? Есть ли конкретный тип, который вы могли бы сократить время запроса, выполняя "работу" асинхронно и возвращая обновление в свой опрос?

На мой взгляд, ajax-запросы всегда должны выполняться довольно быстро, тогда вы можете рассчитать максимальное время одновременного запроса по (время запроса * максимальное количество запросов, которые могут быть инициированы)