Проблемы с использованием Crystal Reports Infoview через Интернет
У нас есть установка Bobje и мы используем Crystal Reports Infoview, чтобы поделиться некоторыми нашими отчетами с нашими клиентами через Интернет. Большинство отчетов будет работать нормально, однако любые отчеты, которые занимают "больше времени", кажутся неудачными. Дольше быть около 3-4 минут. Если мы запускаем те же отчеты в локальной сети, они работают нормально. На самом деле у нас есть некоторые сообщения, которые занимают 10-15 минут, которые возвращаются нормально, но не через Интернет.
Мы связались с SAP по этому поводу и не нашли удовлетворительного решения (пока!!). В основном получить браузер и версию Java. Мы также увеличили как можно больше тайм-аутов, но это никак не отразилось.
Мы сейчас в недоумении о том, что делать дальше. Можно предположить, что это может быть связано с сетью, но я не уверен, с чего начать. Другая идея заключается в том, что это может быть тайм-аут ОС сокета?
Дополнительная информация:
- Сервер RH 4
- Bobje версия XI 3.1 Fix Pack 1.5
- Oracle 10g RAC
Любая помощь приветствуется.
Джеймс
3 ответа
Я думаю, что нашел то, что вы можете использовать:
Решение, которое мы получили, заключалось в том, чтобы обойти эту проблему на стороне Oracle. Мы изменили параметр sqlnet.expire_time в sqlnet.ora на сервере Oracle 10g по сравнению со значением по умолчанию "30" (30 минут) до "1" (1 минута).
Параметр SQLNET.EXPIRE_TIME используется для указания временного интервала в минутах для отправки проверки, чтобы убедиться, что клиент-серверные соединения активны. Если зонд находит разорванное соединение или соединение, которое больше не используется, он возвращает ошибку, в результате чего процесс сервера завершается. Этот параметр в первую очередь предназначен для сервера базы данных, чтобы он мог высвободить ресурсы на стороне сервера, которые не используются.
Побочным эффектом проверки является то, что между клиентом и сервером при каждом выполнении проверки существует активность TCP-IP, и брандмауэр назначает ссылку как активную. Снижая интервал проверки до минуты, нам удалось обмануть брандмауэр, оставив соединения с базой данных в пуле соединений, и не прервать их, даже если клиент не может выполнить запрос с использованием соединения в течение продолжительного периода времени.
Куда идти дальше: я бы взял какой-нибудь сниффер, чтобы точно определить, что происходит. Wireshark - отличный инструмент для устранения проблем, подобных этой. Вы точно увидите, что происходит по сети. Сделайте один базовый захват локально, затем другой с подключением удаленного клиента. Сравните два и посмотрите, где все по-другому.
Мое предположение: где-то в уравнении у вас есть брандмауэр с отслеживанием состояния, который разрывает соединение через определенное количество минут простоя. Некоторый метод поддержки активности TCP был бы необходим для поддержания соединения.
В конце концов я настроил встроенного кота в BO с помощью коннектора ajp. Затем я настроил apache httpd с помощью mod_jk. Это решило проблему.
J