Ошибка system net webexception

Одни и теже задачи, могут быть решены разными средствами. и это хорошо! Проблема лишь в том, чтобы не навредить самому себе! Особенно в ситуации, когда нужно быть готовым, что задачу тебе так перерулят, что от прежней остануться лишь «рожки да ножки».

Исправлено: MichaelD, 06.05.09 09:26

Egaiska

ТЕМА: System.Net.WebException и System.TimeoutException

System.Net.WebException и System.TimeoutException 4 года 2 мес. ago #277

• stepan13
• 
• Offline
• Осваиваюсь на форуме
• 
• Сообщений: 22
• Репутация: 2

System.Net.WebException и System.TimeoutException 4 года 2 мес. ago #279

• 1c43
• 
• Offline
• Новый участник
• 
• Сообщений: 5
• Репутация: 0

System.Net.WebException и System.TimeoutException 4 года 2 мес. ago #284

• MrEeeeq
• Offline
• Администратор
• 
• http://egaiska.ru/forum
• Сообщений: 546
• Спасибо получено: 52
• Репутация: 10

Все вопросы вы можете задать на форуме, а также найти ответы на них:
http://egaiska.ru/forum/

Мы сформируем и сдадим алкогольную декларацию за вас
http://alcodeclarant.ru/

System.Net.WebException и System.TimeoutException 3 года 5 мес. ago #2166

• vvv
• 
• Offline
• Осваиваюсь на форуме
• 
• Сообщений: 26
• Репутация: 0

Такая же проблема.
«Тайм-аут канала запроса во время ожидания ответа после истечения. «

Да есть двойные накладные. При этом один вариант накладной стоит с ошибкой (желтый треугольник) «удалено поставщиком»

Как решать данную проблему?

System.Net.WebException и System.TimeoutException 3 года 5 мес. ago #2167

• zimin
• Offline
• Администратор
• 
• Сообщений: 150
• Спасибо получено: 29
• Репутация: 9

В какой момент происходит эта ошибка? Служба Егаиски при этом запущена? Приходят ли новые накладные?

Да есть двойные накладные. При этом один вариант накладной стоит с ошибкой (желтый треугольник) «удалено поставщиком»

Как решать данную проблему?

System.Net.WebException и System.TimeoutException 3 года 5 мес. ago #2168

• vvv
• 
• Offline
• Осваиваюсь на форуме
• 
• Сообщений: 26
• Репутация: 0

Ошибка возникает после нажатия подтвердить накладную.

Служба УТМ запущена и Егаиской определяется.
Служба ПО «Егаиска» запущена
ПО «Егаиска» посленей версии (при обновлении говорит что обновление не требуется.

Накладные поступают, но также не подтверждаются.

Исправление — System.Net.WebException: Удаленный сервер возвратил ошибку: (500) Ошибка синтаксиса, команда непризнанная

Я создал FTP-код для передачи файлов. Этот код работает отлично, за исключением того, что он иногда вызывает ошибку 500. Точная ошибка —

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

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

При чтении вашего вопроса я был подозрительным, что это связано с (или может быть исправлено) установкой KeepAlive в false . Глядя на SO — этот вопрос ссылается на ту же проблему и указывает на это: qaru.site/questions/962217/…

С KeepAlive , установленным в false , ваше соединение будет закрыто в конце каждого запроса. Если вы передаете большое количество файлов, это может быть проблемой, так как требуется время для повторной передачи учетных данных и т.д. Положительным моментом является воссоздание соединения в известном/начальном состоянии, которое должно решить вашу проблему (даже если это не корень причина).

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

Update:

Если бы я прочитал нижнюю часть ссылки, которую я написал сам, я мог бы ответить еще лучше, команда, которая, вероятно, была переиздана, является частью процесса входа (т.е. USER username ), и это ваша вероятная проблема:

Причина, по которой скейденции больше недействительны, заключается в том, что WebRequest использует аренду, срок действия которого истекает через определенное время. Если вы явно не создаете экземпляр договора аренды и не определяете его тайм-ауты, FtpWebRequest, как представляется, использует значения таймаута по умолчанию. я верю что происходит, когда срок аренды истекает, FtpWebRequest будет затем попробуйте снова войти в систему.

Итак, посмотри здесь с правильным поиском:

позволяет предположить, что ожидаемый запрос по умолчанию не является бесконечным, поскольку указан, но фактически 10000 ms . Что кажется довольно большим расхождением. Таким образом, вы также можете попробовать установить:

И посмотрите, исправляет ли ваша ошибка.

На самом деле не думайте, что это может быть вашей проблемой, поэтому переместите ее на дно:

Кроме того, убедитесь, что ваш request.ReadWriteTimeout подходит для скорости, которую вы видите для большего файла. По умолчанию используется 5 минут, что было бы довольно долго для 290k, поэтому я ожидаю, что это не является источником вашей ошибки. Кроме того, я бы ожидал, что закрытая ошибка соединения, если это была проблема.

Я тоже столкнулся с тем же исключением с FTPWebRequest в рамках настраиваемой задачи MSBuild… к счастью, задача открыла параметр UsePassive=»false» (который устанавливает свойство UsePassive объекта FTPWebRequest ). Изменение значения на «true» устранило проблему. Надеюсь, это поможет!

• (Установить UsePassive to) false , если процесс передачи данных клиентского приложения прослушивает подключение к порту данных; в противном случае true , если клиент должен инициировать подключение к порту данных. Значение по умолчанию: true.
• Настройка свойства UsePassive на true отправляет команду «PASV» на сервер. Эта команда требует, чтобы сервер прослушивал порт данных и ожидал соединение, а не инициировал его при получении команды передачи.
• Если для параметра UsePassive установлено значение true, FTP-сервер может не отправлять размер файла, и процесс загрузки всегда может быть равен нулю. Если для параметра UsePassive установлено значение false , брандмауэр может поднять предупреждение и заблокировать загрузку файла.

Для любого другого, у кого есть эта проблема, и выше, похоже, не работает, я обнаружил, что, когда я ударяю вышеуказанную ошибку, это связано с моим именем пользователя или паролем. Я уверен, что есть немало людей, которые копируют и вставляют из Excel в SQL, поэтому из-за этого SQL подобрал, что мое имя пользователя/пароль снабжено линией возврата каретки (когда вы нажимаете enter).

Мой код фактически взял имя пользователя как «Myusername и vbcrlf».

Надеюсь, что это поможет кому-то, если у них такая же проблема.

Исправление — System.Net.WebException: удаленный сервер вернул ошибку: (500) синтаксическая ошибка, команда не распознана

Я создал код FTP для передачи файлов. Этот код работает нормально, за исключением того, что иногда он вызывает ошибку 500. Точная ошибка заключается в следующем —

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

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

3 Ответа

Прочитав ваш вопрос, я заподозрил, что это связано с установкой KeepAlive в false (или может быть исправлено). Глядя на SO — этот вопрос ссылается на ту же проблему и указывает на нее также: https://stackoverflow.com/a/2071374/1803682

При установке значения KeepAlive на false ваше соединение будет закрыто в конце каждого запроса . Если вы передаете много файлов, это может быть проблемой , так как требуется время для повторной отправки учетных данных и т. д. Плюс заключается в том, что вы воссоздаете соединение в известном / начальном состоянии, которое должно решить вашу проблему (даже если это не является основной причиной).

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

Обновление:

Если бы я прочитал нижнюю часть ссылки, которую я сам разместил, я мог бы ответить еще лучше, команда, вероятно, переиздается, это какая-то часть процесса входа в систему (т. е. USER username ), и это ваша вероятная проблема:

Причина, по которой creadentials больше не может быть действительным, заключается в том, что WebRequest использует аренду, срок действия которой истекает через определенное время. Если вы не создадите явный экземпляр аренды и не определите ее тайм-ауты, FtpWebRequest, похоже, использует значения таймаута по умолчанию. Я верю дело в том, что когда срок аренды истекает, FtpWebRequest будет затем попробуйте снова войти в систему.

Так что ищите здесь с правильным поиском:

получается, что время ожидания запросов по умолчанию не бесконечно, как указано , а фактически 10000 ms . Что кажется довольно большим расхождением. Так что вы также можете попробовать установить:

И посмотрите, исправит ли он вашу ошибку.

Действительно не думаю что это может быть вашей проблемой так что двигайте ее на дно:

Кроме того-проверьте, что ваш request.ReadWriteTimeout соответствует скорости, которую вы видите для большего файла. Значение по умолчанию — 5 минут , что было бы довольно долго для 290k, поэтому я ожидаю, что это не является источником вашей ошибки. Кроме того-я ожидал бы ошибки закрытия соединения, если бы это было проблемой.

Я тоже столкнулся с тем же исключением с FTPWebRequest в пользовательской задаче MSBuild. к счастью, задача выставила параметр UsePassive=»false» (который устанавливает свойство UsePassive для объекта FTPWebRequest ). Изменение значения на «true» исправило проблему. Надеюсь, это поможет!

• (Установите UsePassive в) false , если процесс передачи данных клиентского приложения прослушивает соединение на порту данных; в противном случае true , если клиент должен инициировать соединение на порту данных. Значение по умолчанию- true.
• Установка свойства UsePassive в значение true отправляет команду «PASV» на сервер. Эта команда запрашивает сервер прослушивать порт данных и ждать соединения, а не инициировать его после получения команды передачи.
• Если параметр UsePassive имеет значение true, то сервер FTP может не отправлять размер файла, и прогресс загрузки всегда может быть равен нулю. Если значение UsePassive равно false , брандмауэр может вызвать предупреждение и заблокировать загрузку файла.

Для любого другого человека, у которого есть эта проблема, и выше, кажется, не работает, я обнаружил, что когда я нажал выше ошибку, это было связано с моим именем пользователя или паролем. Я уверен, что есть довольно много людей, которые копируют и вставляют из Excel в SQL, поэтому из-за этого SQL взял, что у моего имени пользователя/пароля была обратная линия каретки(когда вы нажимаете enter).

Мой код фактически взял имя пользователя как «Myusername & vbcrlf».

Надеюсь, что это поможет кому-то, если у них есть такая же проблема.

Похожие вопросы:

Я сделал свое исследование, и я понимаю, что это сообщение об ошибке очень расплывчато. Но мне интересно, может ли кто-нибудь дать мне некоторое представление. У нас есть длинный вызов RIA, который.

Я работаю над проектом target Windows Phone 7.5 и выше. Я использую метод, чтобы получить онлайн-изображение и проверить тип изображения, если это gif, то я буду преобразовывать его в jpg и.

У меня возникла проблема с подключением сервиса Windows к сайту FTP. Я унаследовал сервис Windows от другого разработчика. Служба подключается к стороннему серверу, загружает файл csv и затем.

Я пытаюсь подключиться к веб-сайту, но он продолжает возвращать эту ошибку, хотя я могу добраться до веб-сайта в своем браузере: Исключение типа ‘ System.Net.WebException ‘ произошло в System.dll но.

Я новичок в asp.net, и у моей компании был проект, и все эти деволоперы проекта уходят отсюда , никто не знает о проекте. Мне нужно его обновить. На самом деле все они настроены локально в моей.

У меня есть служба WCF, которая размещена в Службе Windows, а служба windows работает с Local System Account. Служба пытается загрузить файл с сервера SharePoint и не удалось с ошибкой.

Я получаю эту ошибку : (Удаленный сервер вернул ошибку: (500) Внутренняя ошибка сервера. по System.Net.HttpWebRequest.GetResponse()) внезапно в одном из моих windows приложений, сделанных с помощью.

У меня возникли проблемы с небольшим количеством кода, который обращается к веб-сервису restful. При выполнении этого кода он выдает ошибку в var httpResponse =.

Ошибка system net webexception

MichaelD
Автор

Может я чего не догоняю, конечно. Но вот не могу найти: как исправить такую проблему:

После возникновения ошибок в HttpWebRequest типа:

— не могу найти способ, после которого «система бы оставалась работоспособной»,
— т.е. любое последующее действие приводит к «Приложение не отвечает».

Может кто видел/придумал «лекарство»?

Причём, если выполнять из-под отладчика — нигде никаких намёков на проблему нет.

Сейчас нарисую простенький тест.

Исправлено: MichaelD, 02.05.09 12:30

MichaelD
Автор

М-да. видимо я где-то имею другую проблему.
Во всяком случае не в subj .

Т.к. на вот таком коде:

озвученна проблема не проявляется.

MichaelD
Автор

Ну вроде нашёл где собака зарыта.

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

Так вот, вставка вывода в log-файл и его исследование показали, что «после возникновения исключения» (обрабатываемого, конечно) в потоке, «при попытке содании нового потока» (уже после обработки ошибки), приведённый выше код «не работает», а висит на бесконечном цикле:

если далее последить за значением свойства Thread.ThreadState, то оказывается, что

— в случаях стандартных (без ошибок) завершений предшествующих потоков, оно имеет значение: Running
— а в случаях завершений по ошибкам предшествующих потоков, оно имеет значение: Stopped

хотя в обоих случаях поток и создаётся и запускается.

— если вы меня спросите почему так? То ничего определённого я ответить не смогу.
— а вот для того, чтобы приведённый выше код всё-таки заработал, следует «выбросить цикл ожидания ситуации, при которой поток бы «зажил»».

Э. медицинский фак, однако.

Исправлено: MichaelD, 02.05.09 16:12

piva

Сообщений: 18569
Откуда: Курган

Миша, я полное . ничетжесво в шарпе — но даже на первый взгляд Sleep не может сказать «супервайзеру» процессов что он «stopped», если он не известил об этом самого «супервайззера» (термин из EC-1036) — или я не о том ?

MichaelD
Автор

Дык и я так думаю. ну на худой конец Suspended. Да это и не важно, я только что создал новый поток и выполнил у него метод Start(). Как это он сразу после этого может находиться в сатоянии Stopped? Ума не приложу.

Чисто согласно этому я и пытался использовать, т.е.
— «подтормаживать» текущий/главный поток, чтобы за это время «мог развиться» новый запущенный поток.
— и подтормаживать до тех пор, пока вновь запущенный поток не перейдёт в состояние «полнокровного выполнения» (thread.IsAlive)

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

И всё работает вроде именно так. но. до тех пор, пока в потоке (точнее, в потоковом методе) не возникнет исключение. А так как «абсолютно все исключения в рамках потока я перехватываю», типа:

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

Э. под отладчиком во всех ситуациях всё всегда работало. всякие насильные прерывания через Thread.Abort() / Thread.Interrupt() (под отладчиком и без него) тоже не вызывали напряжений.

— проблему обнаружил только из-под exe и только при ошибках типа System.Net.WebException. Грешным делом подумал, что какие-то концы/состояния остаются непочищенными где-нибудь в глубине RAS.
— и какого же было моё удивление, когда увидел, что это именно состояние только что созданного потока на запуске гов..ит. Ну дела.

Хотя код сложный конечно, мог чего-нить и не заметить. А вот исправил ситуацию так, как сказал выше.

Исправлено: MichaelD, 02.05.09 20:10

Igor Korolyov

Во-первых я бы не стал рассчитывать, что твой код с «ожиданием запуска» будет корректно работать ВСЕГДА — ибо остаётся шанс, что исполнение переключится на вновь созданный поток ровно после его запуска, а сам поток отработает «моментально» — ну грубо говоря в пределах одного кванта выделенного времени. В любом случае, этот способ «синхронизации потоков» (даже учитывая что тебе интересует всего то его «внешний» статус) выглядит ненадёжным.
Что касается самой проблемы — для начала надо проверять все статические компоненты классов — возможно там проблема. И возможные проблемы с «утечкой/блокировкой неуправляемых ресурсов». Что печально — проблема может оказаться (хотя это и не обязательно) внутри системных класов — очевидно, что .NET не реализует этот функционал сам — он пользует системную инфраструктуру — возможно не учитывая подобный «способ использования» какой применил ты.

MichaelD
Автор

Нет там никаких статических объектов, кроме т.с. «ресурсных констант». Возможно нарушена где-нибудь посредовательность разгрузки создаваемы/используемых в потоек ресурсов. надо будет порыть в этом направлении.

Вот не поленился, нарисовал тестовый код, сколько-то приблежённый к «боевому»:

но при подёргиваниях его, чёта никаких намёков на проблему не обнаружил.
Видать точно где-то «в консерватории» чегой-то менять надо.

MichaelD
Автор

Сколько-то подёргался вокруг кода «основного приложения».

Э. мистика какая-то. при System.Net.WebException всё как выше описано. Никакие изменения последовательностей разгрузки используемых в потоке ресурсов не помогают, да собственно там и гадать нечего, поскольку при таких падениях никаких ресурсов и не создаётся, до них просто дело не доходит.

Обратил внимание также, что цикл ожидания m_downloadState.thread.IsAlive для случая m_downloadState.thread.ThreadState.ToString() == «Running» вобщем-то бессмысленен, т.к. в этих случаях всегда имеем m_downloadState.thread.IsAlive == true Ну ладненько, отсюда без всякого сожаления выбросил из кода «цикл ожидания запуска потока».

Ну ещё наверное нужно упомянуть, что окно, в котором у меня производится запуск потоков,- это «дочернее окно в рамках MDI-приложения», в отличии от выше приведённого кода-теста.

Вобщем и в этот раз меня MS победил. не буду больше бороться, чтобы докопаться до истины. тем более, что «достоверное решение найдено».

Исправлено: MichaelD, 03.05.09 20:55

Igor Korolyov

Извиняюсь конечно за некоторую назойливость, но я всё равно не понимаю, зачем нужны все эти пляски с бубном — в том числе работа с WM и Interlocked.Exchange — почему бы не сделать так, как рекомендует MSDN — там несколько статей посвящено созданию многопоточных приложений. И даны примеры как надо делать и как не надо — в части взаимодействия основного потока с рабочими (точнее контролов Win-форм, созданных в основном потоке, и кода эти контролы меняющего из рабочих потоков). Я, например, ничего сверх-сложного там не увидел, и от того недоумеваю — зачем было так жестко кодить
Помнится, мы уже обсуждали эту тему. Ну, возможно, чуть в другом аспекте.

MichaelD
Автор

Одному нравится «кислое», другому — «солёное». MSDN исследовал, конечно. и если помнишь, то и код кое-какой при этом писался. Кстати, был мной выложен вот здесь: http://vfpdev.narod.ru/util_r.html#vc_utils — threads5.zip [30.10.2008] (152КБ) — примеры C#-кода (MS VS .NET 2005 + Framework 2.0 [или выше]), показывающие использование классов BackgroundWorker и Thread.

Э. и предоставляется возможность делать выводы каждому свои.

Конкретно мои выводы: если за множество потоков «есть управляющее всем этм безобразием окно» (ну т.е. НЕ СЕРВИС, или что-нибудь в этом роде) то по моим убеждениям, дешевле/гибче наладит общение между «конкретным потоком» и «отображающим ситуацию в потоках окном» средствами: WM и Interlocked.Exchange.
— коду в потоке, «сугубо фиолетово» чего там и как будет представлено пользователю, это не его (потока) проблемы.
— его задачи (сжато/коротко, конечно):