Увеличьте время ожидания GWT Front-End при вызове AsyncCallback
У меня есть пользовательский интерфейс на основе GWT, и он подключается к веб-службе (третья сторона) для отправки нескольких запросов. Когда запрос большой (например, действительно очень большой), приложение использовало время ожидания, так как общее время выполнения запроса третьей стороной составляло 72 секунды, в то время как время ожидания нашего соединения было установлено на 60 секунд, так что даже до того, как ответ поступит от третьей стороны, вне приложения будет тайм-аут. Поэтому я увеличил время ожидания ServiceClient до 60 секунд с 60 секунд. Запрос подается с использованием AsynCallback. Это прекрасно работало на моем локальном сервере IBM WebSphere (DEV Environment).
Проблема в том, что когда я пытаюсь отправить запрос в тестовой среде, пользовательский интерфейс истекает через 60 секунд, и пользователю показывается внутренняя ошибка сервера, но в фоновом режиме AsynCallBack все еще выполняется, и он также выполняет действие после отправки, как только ответ получен. получил (через 72 секунды).
Как удержать тайм-аут пользовательского интерфейса до тех пор, пока AsynCallback не вернет ответ (200 секунд)?
Я не смог найти какие-либо настройки тайм-аута, установленные для интерфейса GWT.
2 ответа
Наконец, проблема была решена путем изменения значения времени ожидания чтения / записи в свойствах подключаемого модуля веб-сервера связанного кластера WebSphere.
Тайм-аут обратного вызова, скорее всего, обрабатывается сервером. Вам нужно будет изменить разъем сервера, чтобы увеличить время ожидания.
Если вы используете tomcat, то ваша проблема заключается в том, что по умолчанию время ожидания разъема составляет 60 секунд. Вы можете изменить это с параметром connectionTimeout.
Если вы выполняете длительные звонки на сервер. Возможно, вы захотите изучить что-то с помощью кометы / толчка, чтобы уведомить клиента о завершении работы. Я использовал несколько процессов для этого в прошлом. Атмосфера - это отличная библиотека, которая поддерживает websockets и http push. Я также использовал очередь с веб-сокетами и STOMP для передачи событий веб-клиентам. Много раз это правильный путь, если вы собираетесь использовать это в производстве. Эта проблема, безусловно, возникнет, если вы когда-нибудь поместите ее за прокси или балансировщик нагрузки.