Telerik Report истекает при удаленном запуске, но не локально - PullRequest
2 голосов
/ 29 октября 2011

Надеюсь, я смогу объяснить это правильно ..

Приложение Silverlight Telerik Reports (в отдельном классе) Веб-приложение, в котором размещается Silverlight - предоставляет доступ к отчетам через ReportService.svc, который указывает на Telerik.Report.Server.dll.

Разработано на моей машине и все работает нормально. Был один отчет о том, что с определенными объемами данных истекал тайм-аут, поэтому через Google и т. Д. Мне удалось правильно настроить параметры через настройки httpBinding, IIS и т. Д., И я решил проблему. Теперь отчет работает нормально.

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

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

Таким образом, ЕДИНСТВЕННОЕ различие в этих двух настройках заключается в том, что он работает в браузере на сервере, но не на моем компьютере, подключенном к тому же серверу.

Есть предположения, в чем может быть проблема? Это очень и очень странно. Это потому, что приложение Silverlight на самом деле работает на локальном компьютере и истекло время ожидания?

Время, о котором мы говорим, может составить 75 секунд для генерации большого отчета. Не несколько минут или что-нибудь.

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

Odd ...

UPDATE:

Итак ... используя Fiddler, я посмотрел на звонки из IE и Firefox. Они одинаковые. Разница лишь в том, что Firefox / Telerik закрывает соединение примерно через 30 секунд. Результат все еще возвращается, но Firefox больше не слушает. Но если я посмотрю на ответ от IE / Firefox, они одинаковы. Либо IE поддерживает соединение открытым, либо Firefox закрывает его преждевременно. Это не проблема брандмауэра, как это происходит, когда все на одной машине.

1 Ответ

2 голосов
/ 01 ноября 2011

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

Только позже я узнал, что тайм-аут на самом деле произошел в диспетчере сетевого трафика (в данном случае ZXTM, но это не имеет значения). Имя хоста, которое использовалось для доступа к службе, было на самом деле зарегистрировано диспетчером трафика, а не сервером напрямую, поэтому весь трафик направлялся через ZXTM. И у этого был глобальный тайм-аут 40 секунд.

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

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

...