Ограничение потоков менеджеров работ и страница не могут быть отображены

У нас есть интенсивная обработка памяти для определенных функций, и мы хотели бы ограничить количество параллельных запросов для этой обработки. Мы можем настроить с помощью «Диспетчеров работ» в WebLogic и установить ограничение на количество потоков для этого сервлета.

Например, если мы установим максимальное ограничение потоков равным 3, то при наличии 10 параллельных запросов; 7 запросов в очереди. Могут быть ситуации, когда эти запросы, ожидающие в очереди, могут обрабатываться до 30-40 минут. Мы провели простое тестирование, и полученная страница не может быть отображена из-за тайм-аута через 15 минут, а сообщение получено через 1 час.

Кто-нибудь знает, есть ли в WebLogic параметр для увеличения/уменьшения времени ожидания и предотвращения невозможности отображения страницы?

Ценю, если у кого-то есть мысли по этому поводу.


person Community    schedule 04.11.2009    source источник
comment
Привет, я читал, что тайм-аут по умолчанию для IE6 составляет 60 секунд. Означает ли это, что пользователь увидит, что страница не может быть отображена, если ответ не получен от сервера в течение 60 секунд?   -  person    schedule 05.11.2009


Ответы (3)


Кто-нибудь знает, есть ли в WebLogic параметр для увеличения/уменьшения времени ожидания и предотвращения невозможности отображения страницы?

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

Итак, на мой взгляд, правильный ответ здесь: используйте асинхронность, это идеальный вариант использования. Когда пользователь нажимает кнопку, отправьте сообщение JMS в очередь (или создайте задание Quartz) и отправьте пользователю страницу с идентификатором запроса, сообщающую ему вернуться позже. Когда обработка будет завершена, обновите где-нибудь статус и сделайте статус/результат доступным для пользователя. Действительно, пользовательский опыт будет лучше, и вы столкнетесь с меньшими проблемами, чем с браузером.

person Pascal Thivent    schedule 05.11.2009

1) Используйте другой инструмент (не браузер), например WGET, где вы можете управлять параметром тайм-аута (--timeout).

2) Почему вы используете HTTP? Используйте bean-компоненты, управляемые сообщениями, и отправьте сообщение JMS, и не заботьтесь о тайм-аутах.

person Andrey Adamovich    schedule 04.11.2009
comment
Спасибо за ответ. Вышеупомянутая обработка начинается, когда пользователь нажимает кнопку, и мы не возражаем против того, чтобы пользователь ждал, пока это обрабатывается. Итак, хотелось бы проверить, выполняется ли запрос на сервер, и сервер занимает около 30 минут, истекает ли время ожидания браузера? - person ; 05.11.2009
comment
У вас хорошие пользователи :). Я бы подождал 30 минут ;). Почему бы вам просто не отправить сообщение JMS при нажатии кнопки и не позволить пользователю делать другие вещи? И у вас также может быть какая-то другая страница, где пользователь может узнать статус задания. - person Andrey Adamovich; 05.11.2009
comment
Что касается времени ожидания, я думаю, что оно зависит от многих факторов, не только от браузера, но и, возможно, от времени ожидания вашего маршрутизатора, сетевого драйвера и т. д. Например, в FireFox вы можете установить время ожидания, используя эти параметры network.http.connect. тайм-аут и network.http.request.timeout (forums.techguy.org/web-email/). - person Andrey Adamovich; 05.11.2009

Возможно, кварц может сделать то, что вам нужно? Начать работу и проверять ее по мере необходимости?

person John Liptak    schedule 26.11.2009