Практическое значение параметра 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 подавляется, и отображаются только вторичные исключения NullPointerExceptions и @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-запросы всегда должны выполняться довольно быстро, тогда вы можете рассчитать максимальное время одновременного запроса по (время запроса * максимальное количество запросов, которые могут быть инициированы)