2016-06-24 1 views
0

У меня есть 2 ASP.NET MVC веб-приложения, следующим образом: -Changing моего кода, чтобы использовать методы асинхронных вместо методов синхронизации заставит мой WebClient, чтобы никогда не таймаут (20 минут ++)

  1. ApplicationA. который представляет собой Asp.net mvc-4, развернутый под iis-8.

  2. ПриложениеB. который представляет собой Asp.net mvc-5, развернутый под iis-8.

Теперь в моем ApplicationA я следующий метод, который будет вызывать метод действия (дом/синхронизации) на applicationB, следующим образом: -

public List<Technology> GetTechnology(int? currentfiltertype) 
    { 
    try 
     { 
     using (WebClient wc = new WebClient()) 
     { 
      string url = currentURL + "home/sync?filtertype=" + currentfiltertype; 
      wc.Headers.Add("Authorization", token); 
      string json = wc.DownloadString(url); 
      List<Technology> result = JsonConvert.DeserializeObject<List<Technology>>(json); 
      return result; 
     } 
     } 
     catch (Exception e){} 
    } 

теперь я отметил, что, когда в WebClient вызывает метод действия, и метод не получил ответ в течение примерно 2 минут, он будет вызывать исключение таймаута. Но поскольку метод действия home/sync в веб-приложении B требуется около 30 минут для завершения. Поэтому я искал решение о продлении периода ожидания веб-клиента. поэтому я попытался изменить мой код, чтобы использовать методы асинхронное, как следует, в основном, путем замены wc.DownloadString с wc.DownloadStringTaskAsync следующим образом: -

public async Task<List<Technology>> GetTechnology(int? currentfiltertype) 
{ 
    try 
    { 
     using (WebClient wc = new WebClient()) 
     { 
     string url = currentURL + "home/sync?filtertype=" + currentfiltertype; 
     wc.Headers.Add("Authorization", token); 
     string json = await wc.DownloadStringTaskAsync(url); 
     List<Technology> result = JsonConvert.DeserializeObject<List<Technology>>(json); 
     return result; 
     } 
    } 
    catch (Exception e) {} 
} 

и теперь кажется, что WebClient никогда не истек ... я пытался вызвать метод действий и веб клиент продолжает ждать ответа более 20 минут без привлечения исключения тайм-аута, после чего он получил ответ от веб-приложения B, и все сработало хорошо. так может кто-нибудь советовать, почему сменить мой код на использование методов async, как показано в приведенном выше коде , вызвало WebClient не время ожидания? я не могу понять связь между использованием асинхронной логики и продлением периода ожидания для веб-клиента (не уверен, что WebClient будет когда-либо тайм-аут внутри асинхронных методов!)?

+2

Все, что занимает 30 минут, должно * * не работать в веб-приложении. Если вам нужно выполнить какую-то долговременную задачу, вы должны разгрузить ее в фоновый процесс. –

+0

@ChrisPratt да, вы правы, я всегда определяю длительные процессы в отдельных консольных приложениях, но для этого мне нужно запустить его под IIS, поскольку он будет генерировать отчет, поэтому, если пул приложений перезапускается во время длительная операция, то нет реального ущерба для моих данных, в этом случае пользователю необходимо регенерировать отчет. –

+0

Почему кто-то голосует ЗАКРЫТЬ этот вопрос, по какой-либо причине? –

ответ

3

Может ли кто-нибудь посоветовать, почему сменить мой код на использование методов async, как показано в приведенном выше коде, вызвало ли WebClient не время ожидания?

Ответ немного запутан: WebClient is based on WebRequest и HttpWebRequest's Timeout property is only honored for synchronous requests.

(noy sure, если WebClient будет когда-либо тайм-аут внутри асинхронных методов!)?

Это не непосредственно поддержка асинхронных тайм-ауты, но он поддерживает (its own kind of) cancellation, который вы можете вызвать после таймера.

+0

большое спасибо за ваш полезный ответ. поэтому, когда я использую «wait wc.DownloadStringTaskAsync (url)»; это никогда не будет тайм-аут, это правильно? второй questino, каков недостаток, если я сохраню свой асинхронный код как есть? так что это никогда не будет тайм-аут для вызовов веб-клиентов? –

+0

@johnG: Он никогда не будет тайм-аутом на стороне клиента; по-прежнему возможно, чтобы время ожидания сервера и отправить ответ об ошибке. Если вы сохраняете свой код как есть (без тайм-аута), тогда у вас не будет тайм-аута клиента. –

+0

теперь, когда вы говорите, что никогда не будет тайм-аут на клиенте, тогда вы имеете в виду, что WebClient, использующий метод async, никогда не будет тайм-аут .. но мне непонятно, что вы подразумеваете под этим, может быть тайм-аут на сервере ??? почему серверный тайм-аут? –

Смежные вопросы