Runtime: एचटीपी क्लाइंट टाइमआउट पर टास्क रद्द किए गए अपवाद को फेंकता है

@awithy आप .NET Core के किस संस्करण का उपयोग कर रहे हैं?

1.1

सही डिज़ाइन या नहीं, डिज़ाइन द्वारा ऑपरेशन रद्द किए गए अपवादों को टाइमआउट के लिए फेंक दिया जाता है (और टास्क रद्द किया गया अपवाद एक ऑपरेशन रद्द किया गया अपवाद है)।
cc: @davidsh

हमारी टीम को यह सहज नहीं लगा, लेकिन ऐसा लगता है कि यह डिज़ाइन के अनुसार काम कर रहा है। दुर्भाग्य से, जब हमने इसे मारा, तो हमने रद्द करने का स्रोत खोजने का प्रयास करने में थोड़ा समय बर्बाद किया। इस परिदृश्य को कार्य रद्द करने से अलग तरीके से संभालना बहुत बदसूरत है (हमने इसे प्रबंधित करने के लिए कस्टम हैंडलर बनाया है)। यह भी एक अवधारणा के रूप में रद्दीकरण का अति प्रयोग प्रतीत होता है।

आपको त्वरित प्रतिक्रिया के लिए फिर से धन्यवाद।

ऐसा लगता है कि डिज़ाइन + पिछले 6+ महीनों में केवल 2 ग्राहकों ने शिकायत की थी।
समापन।

@karelz इस भ्रामक अपवाद से प्रभावित एक अन्य ग्राहक के रूप में एक नोट जोड़ रहा है :)

जानकारी के लिए धन्यवाद, कृपया शीर्ष पोस्ट को भी अपवोट करें (समस्याओं को इसके द्वारा हल किया जा सकता है), धन्यवाद!

सही डिज़ाइन या नहीं, डिज़ाइन द्वारा ऑपरेशन रद्द किए गए अपवाद टाइमआउट के लिए फेंक दिए जाते हैं

यह एक खराब डिजाइन आईएमओ है। यह बताने का कोई तरीका नहीं है कि क्या अनुरोध वास्तव में रद्द कर दिया गया था (यानी रद्दीकरण टोकन SendAsync को रद्द कर दिया गया था) या यदि समय समाप्त हो गया था। बाद के मामले में, यह फिर से प्रयास करने के लिए समझ में आता है, जबकि पूर्व मामले में ऐसा नहीं होगा। एक TimeoutException है जो इस मामले के लिए एकदम सही होगा, इसका उपयोग क्यों न करें?

हाँ, इसने हमारी टीम को भी एक पाश के लिए फेंक दिया। इससे निपटने की कोशिश करने के लिए समर्पित एक संपूर्ण स्टैक ओवरफ़्लो थ्रेड है:

मैंने कुछ दिन पहले एक वर्कअराउंड प्रकाशित किया था: https://www.thomaslevesque.com/2018/02/25/better-timeout-handling-with-httpclient/

बहुत अच्छे धन्यवाद।

ब्याज के रूप में फिर से खोलना अब बड़ा है - स्टैक ओवरफ्लो थ्रेड में अब 69 अपवोट हैं।

सीसी @ डॉटनेट/एनसीएल

कोई खबर ? अभी भी डॉटनेट कोर 2.0 . में होता है

यह 2.1 के बाद की शीर्ष समस्याओं की हमारी सूची में है। हालांकि इसे 2.0/2.1 में तय नहीं किया जाएगा।

टाइमआउट होने पर हमारे पास कई विकल्प हैं:

1. TaskCanceledException के बजाय TaskCanceledException TimeoutException फेंकें।
   
   
   
   • प्रो: रनटाइम पर स्पष्ट रद्दीकरण कार्रवाई से टाइमआउट को अलग करना आसान है
   
   
   • कॉन: तकनीकी ब्रेकिंग परिवर्तन - नए प्रकार का अपवाद फेंक दिया गया है।
   
   
2. TaskCanceledException को आंतरिक अपवाद के साथ TimeoutException के रूप में फेंक दें
   
   
   
   • प्रो: रनटाइम पर स्पष्ट रद्दीकरण कार्रवाई से टाइमआउट को अलग करना संभव है। संगत अपवाद प्रकार।
   
   
   • खुला प्रश्न: क्या InnerException ( TimeoutException.InnerException के रूप में) को संरक्षित करते हुए मूल TaskCanceledException स्टैक को फेंकना और एक नया फेंकना ठीक है? या हमें मूल TaskCanceledException को संरक्षित और लपेटना चाहिए?
     
     
     
     
     
     • या तो: नया कार्य रद्द अपवाद -> नया टाइमआउट अपवाद -> मूल कार्य रद्द किया गया अपवाद (मूल आंतरिक अपवाद के साथ जो शून्य हो सकता है)
     
     
     
     • या: नया कार्य रद्द अपवाद -> नया टाइमआउट अपवाद -> मूल कार्य रद्द अपवाद। इनर अपवाद (शून्य हो सकता है)
     
     
     
   
   
3. कारण के रूप में टाइमआउट का उल्लेख करने वाले संदेश के साथ TaskCanceledException फेंकें
   
   
   
   • प्रो: संदेश / लॉग से स्पष्ट रद्दीकरण कार्रवाई से टाइमआउट को अलग करना संभव है
   
   
   • Con: रनटाइम पर अलग नहीं किया जा सकता है, यह "केवल डीबग" है।
   
   
   • खुला प्रश्न: [2] जैसा ही है - क्या हमें मूल टास्क रद्द किए गए अपवाद को लपेटना या बदलना चाहिए (और यह ढेर)
   
   

मैं मूल TaskCanceledException के मूल स्टैक को हटाने के साथ विकल्प [2] की ओर झुक रहा हूं।
@stephentoub @davidsh कोई विचार?

बीटीडब्लू: परिवर्तन HttpClient.SendAsync में काफी सरल होना चाहिए जहां हम टाइमआउट सेट अप करते हैं:
https://github.com/dotnet/corefx/blob/30fb78875148665b98748ede3013641734d9bf5c/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L433 -L461

शीर्ष-स्तरीय अपवाद हमेशा एक HttpRequestException होना चाहिए। यह HttpClient के लिए मानक API मॉडल है।

उसके भीतर, आंतरिक अपवाद के रूप में, "टाइमआउट" शायद टाइमआउट अपवाद होना चाहिए। वास्तव में, यदि हम इसे अन्य मुद्दों के साथ जोड़ते हैं (WebExceptionStatus के समान एक नई एनम संपत्ति को शामिल करने के लिए HttpRequestion को संशोधित करने के बारे में), तो डेवलपर्स को केवल उस एनम की जांच करनी होगी और आंतरिक अपवादों का निरीक्षण नहीं करना होगा।

यह मूल रूप से विकल्प 1 है) लेकिन वर्तमान ऐप-संगत एपीआई मॉडल को संरक्षित करना जारी रखता है कि एचटीपी क्लाइंट एपीआई से शीर्ष-स्तरीय अपवाद हमेशा HttpRequestException होते हैं।

ध्यान दें: स्ट्रीम एपीआई से सीधे HTTP प्रतिक्रिया स्ट्रीम पढ़ने से कोई भी "टाइमआउट" जैसे:

```सी#
वर क्लाइंट = नया HttpClient ();
स्ट्रीम प्रतिक्रियास्ट्रीम = क्लाइंट की प्रतीक्षा करें। GetStreamAsync (यूआरएल);

int बाइट्सरेड = प्रतिक्रिया का इंतजार करें। ReadAsync (बफर, 0, बफर। लंबाई);
```

System.IO.IOException आदि को शीर्ष-स्तरीय अपवादों के रूप में फेंकना जारी रखना चाहिए (हमारे पास वास्तव में इसके बारे में SocketsHttpHandler में कुछ बग हैं)।

@davidsh क्या आप HttpRequestException फेंकने का सुझाव दे रहे हैं, यहां तक ​​​​कि उन मामलों में भी जब स्पष्ट उपयोगकर्ता रद्दीकरण होता है? वे आज TaskCanceledException फेंकते हैं और यह ठीक लगता है। सुनिश्चित नहीं है कि यह कुछ ऐसा है जिसे हम बदलना चाहते हैं ...
मैं क्लाइंट-साइड टाइमआउट को HttpRequestException के बजाय TaskCanceledException #$2$#$ के रूप में बेनकाब करना ठीक हूं।

@davidsh क्या आप स्पष्ट उपयोगकर्ता रद्दीकरण होने पर भी HttpRequestException को फेंकने का सुझाव दे रहे हैं? वे आज टास्क रद्द किए गए अपवाद को फेंक देते हैं और यह ठीक लगता है। सुनिश्चित नहीं है कि यह कुछ ऐसा है जिसे हम बदलना चाहते हैं …

इससे पहले कि मैं इस प्रश्न का उत्तर दे सकूं, मुझे सटीक वर्तमान व्यवहारों को सत्यापित करने के लिए .NET फ्रेमवर्क सहित स्टैक के विभिन्न व्यवहारों का परीक्षण करने की आवश्यकता है।

साथ ही, कुछ मामलों में, हमारे कुछ स्टैक ऑपरेशन रद्द किए गए अपवाद के आंतरिक अपवाद के साथ HttpRequestException को फेंक रहे हैं। कार्य रद्द अपवाद ऑपरेशन रद्द अपवाद का एक व्युत्पन्न प्रकार है।

जब स्पष्ट उपयोगकर्ता रद्दीकरण होता है

हमें "स्पष्ट" क्या है, इसकी स्पष्ट परिभाषा की भी आवश्यकता है। उदाहरण के लिए, HttpClient.Timeout गुण "स्पष्ट" सेट कर रहा है? मुझे लगता है कि हम नहीं कह रहे हैं। कैंसिलेशन टोकनसोर्स ऑब्जेक्ट पर .Cancel() को कॉल करने के बारे में क्या है (जो कैंसिलेशन टोकन ऑब्जेक्ट में पारित को प्रभावित करता है)? क्या वह "स्पष्ट" है? शायद ऐसे और भी उदाहरण हैं जिनके बारे में हम सोच सकते हैं।

जब आप HttpClient.Timeout सेट करते हैं तो .NET Framework टास्क रद्द अपवाद भी फेंकता है।

यदि आप क्लाइंट से रद्दीकरण और कार्यान्वयन से रद्द करने के बीच अंतर नहीं कर सकते हैं - बस दोनों की जांच करें। क्लाइंट टोकन का उपयोग करने से पहले व्युत्पन्न एक बनाएं:
```सी#
वर क्लाइंटटोकन = ....
var innerTokenSource = CancellationTokenSource.CreateLinkedTokenSource (क्लाइंटटोकन);

If at some point you catch **OperationCancelledException**:
```c#
try
{
     //invocation with innerToken
}
catch(OperationCancelledException oce)
{
      if(clientToken.IsCancellationRequested)
          throw; //as is, it is client initiated and in higher priority
      if(innerToken.IsCancellationRequested)
           //wrap it in HttpException, TimeoutException, whatever, wrap it in another linked token until you process all cases.
}

मूल रूप से आप क्लाइंट टोकन से गहरे तक सभी संभावित परतों को फ़िल्टर करते हैं, जब तक कि आपको टोकन नहीं मिल जाता है जो रद्दीकरण का कारण बनता है।

इस पर कोई अपडेट 2.2 या 3.0 बना रहा है? @karelz @davidsh , cc @NickCraver । मेरी इच्छा है कि यह टाइमआउट अपवाद फेंकने का विकल्प 1 करेगा, या वैकल्पिक रूप से एक नया एचटीपीटाइमआउट अपवाद जो HttpRequestException से लिया गया है। धन्यवाद!

इस पर कोई अपडेट 2.2 या 3.0 बना रहा है?

2.2 के लिए बहुत देर हो चुकी है, इसे पिछले हफ्ते जारी किया गया था;)

2.2 के लिए बहुत देर हो चुकी है, इसे पिछले हफ्ते जारी किया गया था;)

अर्घ, जब मैं ब्रेक लेता हूं तो यही होता है;)

थोड़ा नासमझ होने के बावजूद, मैंने जो सबसे सरल समाधान पाया है, वह है ऑपरेशन कैंसिल्ड एक्सेप्शन के लिए एक कैच हैंडलर को घोंसला बनाना और फिर यह निर्धारित करने के लिए कि रद्दीकरण टोकन एक टाइमआउट या वास्तविक सत्र गर्भपात का परिणाम था या नहीं, IsCancellationRequested के मूल्य का मूल्यांकन करना है। स्पष्ट रूप से एपीआई कॉल करने वाला तर्क व्यावसायिक तर्क या सेवा परत में होगा लेकिन मैंने सादगी के लिए उदाहरण समेकित किया है:

````सीशार्प
[एचटीपीगेट]
सार्वजनिक async कार्यइंडेक्स (रद्दीकरण टोकन रद्दीकरण टोकन)
{
कोशिश करो
{
// यह सामान्य रूप से नियंत्रक के बजाय एक व्यावसायिक तर्क या सेवा परत में किया जाएगा, लेकिन मैं यहाँ सरलता के लिए बिंदु का वर्णन कर रहा हूँ
कोशिश करो
{
// HttpClient उदाहरणों के लिए HttpClientFactory का उपयोग करना
वर httpClient = _httpClientFactory.CreateClient ();

        //Set an absurd timeout to illustrate the point
        httpClient.Timeout = new TimeSpan(0, 0, 0, 0, 1);

        //Perform call that requires special timeout logic                
        var httpResponse = await httpClient.GetAsync("https://someurl.com/api/long/running");

        //... (if GetAsync doesn't fail, handle the response as desired)
    }
    catch (OperationCanceledException innerOperationCanceled)
    {
        //If a canceled token exception occurs due to a timeout, "IsCancellationRequested" should be false
        if (cancellationToken.IsCancellationRequested)
        {
            //Bubble exception to global handler
            throw innerOperationCanceled;
        }
        else
        {
            //... (perform timeout logic here)
        }                    
    }                

}
catch (OperationCanceledException operationCanceledEx)
{
    _logger.LogWarning(operationCanceledEx, "Request was aborted by the end user.");
    return new StatusCodeResult(499);
}
catch (Exception ex)
{
    _logger.LogError(ex, "An unexepcted error occured.");
    return new StatusCodeResult(500);
}

}
````

मैंने इस परिदृश्य को और अधिक सुरुचिपूर्ण ढंग से संभालने के बारे में अन्य लेख देखे हैं, लेकिन उन सभी को पाइपलाइन आदि में खुदाई करने की आवश्यकता है। मुझे एहसास है कि यह दृष्टिकोण मेरी आशा से सही नहीं है कि भविष्य के साथ वास्तविक टाइमआउट अपवादों के लिए बेहतर समर्थन होगा। रिहाई।

एचटीटीपी क्लाइंट के साथ काम करना पूरी तरह से लाजवाब है। HttpClient को हटा दिया जाना चाहिए और खरोंच से शुरू किया जाना चाहिए।

थोड़ा नासमझ होने के बावजूद, मैंने जो सबसे सरल समाधान पाया है, वह है ऑपरेशन कैंसिल्ड एक्सेप्शन के लिए एक कैच हैंडलर को घोंसला बनाना और फिर यह निर्धारित करने के लिए कि रद्दीकरण टोकन एक टाइमआउट या वास्तविक सत्र गर्भपात का परिणाम था या नहीं, IsCancellationRequested के मूल्य का मूल्यांकन करना है। स्पष्ट रूप से एपीआई कॉल करने वाला तर्क व्यावसायिक तर्क या सेवा परत में होगा लेकिन मैंने सादगी के लिए उदाहरण समेकित किया है:

[HttpGet]
public async Task<IActionResult> Index(CancellationToken cancellationToken)
{
  try
  {
      //This would normally be done in a business logic or service layer rather than in the controller itself but I'm illustrating the point here for simplicity sake
      try
      {
          //Using HttpClientFactory for HttpClient instances      
          var httpClient = _httpClientFactory.CreateClient();

          //Set an absurd timeout to illustrate the point
          httpClient.Timeout = new TimeSpan(0, 0, 0, 0, 1);

          //Perform call that requires special timeout logic                
          var httpResponse = await httpClient.GetAsync("https://someurl.com/api/long/running");

          //... (if GetAsync doesn't fail, handle the response as desired)
      }
      catch (OperationCanceledException innerOperationCanceled)
      {
          //If a canceled token exception occurs due to a timeout, "IsCancellationRequested" should be false
          if (cancellationToken.IsCancellationRequested)
          {
              //Bubble exception to global handler
              throw innerOperationCanceled;
          }
          else
          {
              //... (perform timeout logic here)
          }                    
      }                

  }
  catch (OperationCanceledException operationCanceledEx)
  {
      _logger.LogWarning(operationCanceledEx, "Request was aborted by the end user.");
      return new StatusCodeResult(499);
  }
  catch (Exception ex)
  {
      _logger.LogError(ex, "An unexepcted error occured.");
      return new StatusCodeResult(500);
  }
}

मैंने इस परिदृश्य को और अधिक सुरुचिपूर्ण ढंग से संभालने के बारे में अन्य लेख देखे हैं, लेकिन उन सभी को पाइपलाइन आदि में खुदाई करने की आवश्यकता है। मुझे एहसास है कि यह दृष्टिकोण मेरी आशा से सही नहीं है कि भविष्य के साथ वास्तविक टाइमआउट अपवादों के लिए बेहतर समर्थन होगा। रिहाई।

यह बिल्कुल बेतुका है कि हमें इस नृशंस कोड को लिखने की आवश्यकता है। HttpClient Microsoft द्वारा बनाया गया अब तक का सबसे लीकी एब्स्ट्रैक्शन है

मैं मानता हूं कि टाइमआउट के आसपास अधिक विशिष्ट अपवाद जानकारी शामिल नहीं करने के लिए ऐसा लगता है कि यह बहुत ही कम है। लोगों के लिए रद्द किए गए टोकन अपवादों की तुलना में वास्तविक टाइमआउट को अलग-अलग संभालना चाहते हैं, यह एक बहुत ही बुनियादी चीज की तरह लगता है।

एचटीटीपी क्लाइंट के साथ काम करना पूरी तरह से लाजवाब है। HttpClient को मिटाने और नए सिरे से शुरू करने की जरूरत है।\

यह बहुत उपयोगी या रचनात्मक प्रतिक्रिया नहीं है @dotnetchris । ग्राहक और MSFT कर्मचारी समान रूप से चीजों को बेहतर बनाने की कोशिश करने के लिए यहां हैं, और यही कारण है कि @karelz जैसे लोग अभी भी यहां ग्राहकों की प्रतिक्रिया सुन रहे हैं और सुधार करने की कोशिश कर रहे हैं। उनके लिए खुले में विकास करने की कोई आवश्यकता नहीं है, और उनकी सद्भावना को नकारात्मकता से नहीं जलाना चाहिए या वे अपनी गेंद लेने और घर जाने का फैसला कर सकते हैं, और यह समुदाय के लिए और भी बुरा होगा। धन्यवाद! :)

क्यों न केवल एक HttpClient2 (अस्थायी नाम) बनाया जाए, जिसमें अपेक्षित व्यवहार हो और दस्तावेज़ीकरण में सूचित किया जाए, कि "HttpClient अप्रचलित है, कृपया HttpClient2 का उपयोग करें" और उनमें से 2 के बीच के अंतर को समझाया।

इस तरह .NetFramework में कोई ब्रेकिंग परिवर्तन नहीं डाला जाता है।

HttpClient अपवादों को फेंकने पर आधारित नहीं होना चाहिए। यह असाधारण नहीं है कि एक इंटरनेट होस्ट अनुपलब्ध है। यह वास्तव में अपेक्षित है, पतों के अनंत क्रमपरिवर्तन को देखते हुए, असाधारण मामला इसे कुछ ऐसा दे रहा है जो काम करता है।

मैंने यह भी ब्लॉग किया कि 3 साल पहले HttpClient का उपयोग करना कितना बुरा है। https://dotnetchris.wordpress.com/2015/12/11/working-with-httpclient-is-absurd/

यह स्पष्ट रूप से खराब डिजाइन है।

क्या माइक्रोसॉफ्ट में किसी ने भी एचटीपी क्लाइंट का इस्तेमाल किया है? यह निश्चित रूप से ऐसा नहीं लगता है।

फिर इस भयानक एपीआई सतह से परे, इसके निर्माण और थ्रेडिंग के संबंध में सभी प्रकार के लीकी एब्स्ट्रैक्शन हैं। मुझे विश्वास नहीं हो रहा है कि इसे बचाया जा सकता है और केवल बिल्कुल नया ही एक व्यवहार्य समाधान है। HttpClient2, HttpClientSlim ठीक है या जो भी हो।

एचटीपी एक्सेस को कभी भी अपवाद नहीं फेंकना चाहिए। इसे हमेशा परिणाम वापस करना चाहिए, परिणाम पूरा होने, टाइमआउट, http प्रतिक्रिया के लिए निरीक्षण करने में सक्षम होना चाहिए। इसे फेंकने की अनुमति देने का एकमात्र कारण यह है कि यदि आप EnsureSuccess() आह्वान करते हैं तो दुनिया में किसी भी अपवाद को फेंकना ठीक है। लेकिन इंटरनेट के पूरी तरह से सामान्य व्यवहार के लिए शून्य नियंत्रण प्रवाह प्रबंधन होना चाहिए: होस्ट अप, होस्ट नॉट अप, होस्ट टाइमआउट। उनमें से कोई भी असाधारण नहीं है।

HttpClient अपवादों को फेंकने पर आधारित नहीं होना चाहिए। यह असाधारण नहीं है कि एक इंटरनेट होस्ट अनुपलब्ध है। यह वास्तव में अपेक्षित है, पतों के अनंत क्रमपरिवर्तन को देखते हुए, असाधारण मामला इसे कुछ ऐसा दे रहा है जो काम करता है।

@dotnetchris चूंकि ऐसा लगता है कि आपको इस विषय के लिए बहुत जुनून है, क्यों न HttpClient2 के लिए अपना प्रस्तावित पूर्ण API लिखने के लिए समय निकालें और इसे एक नए मुद्दे के रूप में चर्चा के लिए टीम को सबमिट करें?

मैंने गहरे तकनीकी स्तर से एचटीपी क्लाइंट को अच्छा या बुरा बनाने वाले नट और बोल्ट में गोता लगाने की जहमत नहीं उठाई है, इसलिए मेरे पास @dotnetchris की टिप्पणियों में जोड़ने के लिए कुछ भी नहीं है। मुझे निश्चित रूप से नहीं लगता कि एमएस देव टीम की आलोचना करना उचित है, लेकिन मैं यह भी समझता हूं कि परिस्थितियों के समाधान के लिए घंटों और घंटों खर्च करना कितना निराशाजनक है, ऐसा लगता है कि इसे संभालना बहुत आसान होना चाहिए। यह समझने के लिए संघर्ष करने की निराशा है कि कुछ निर्णय/परिवर्तन क्यों किए गए थे, उम्मीद है कि एमएस में कोई व्यक्ति इस बीच अपना काम पूरा करने और वितरित करने की कोशिश करते समय चिंता का समाधान करेगा।

मेरे मामले में, मेरे पास एक बाहरी सेवा है जिसे मैं उपयोगकर्ता भूमिकाओं को स्थापित करने के लिए OAuth प्रक्रिया के दौरान कॉल करता हूं और यदि वह कॉल समय एक निर्दिष्ट समय अवधि के भीतर समाप्त हो जाता है (जो दुर्भाग्य से मेरी इच्छा से अधिक होता है), मुझे एक माध्यमिक विधि पर वापस जाने की आवश्यकता है .

वास्तव में अन्य कारणों के असंख्य हैं जो मैं देख सकता हूं कि कोई टाइमआउट और रद्दीकरण के बीच अंतर करने में सक्षम क्यों होना चाहता है। इस तरह के एक सामान्य परिदृश्य के लिए बेहतर समर्थन मौजूद नहीं है, जिसे मैं समझने के लिए संघर्ष करता हूं और मुझे वास्तव में उम्मीद है कि यह कुछ ऐसा है जिस पर एमएस टीम कुछ अतिरिक्त विचार करेगी।

@karelz 3.0 के लिए शेड्यूल पर इसे प्राप्त करने के लिए क्या आवश्यक होगा, किसी से एपीआई प्रस्ताव?

यह एपीआई प्रस्ताव के बारे में नहीं है। यह सही कार्यान्वयन खोजने के बारे में है। यह हमारे 3.0 बैकलॉग पर है और सूची में काफी ऊपर है (HTTP/2 और एंटरप्राइज़ परिदृश्यों के पीछे)। हमारी टीम द्वारा 3.0 में संबोधित करने का यह बहुत अच्छा मौका है।
बेशक अगर समुदाय में कोई प्रेरित होता है, तो हम भी योगदान देंगे।

@karelz इस मामले में समुदाय कैसे मदद कर सकता है? एपीआई प्रस्ताव की आवश्यकता होने पर मैंने इसका कारण बताया कि मैं आपके संदेश से निश्चित नहीं था जो शुरू होता है "हमारे पास कई विकल्प हैं कि समय समाप्त होने पर क्या करना है:" यदि टीम ने आपके द्वारा सूचीबद्ध विकल्पों में से अपने पसंदीदा विकल्प पर फैसला किया था। यदि आपने कोई दिशा तय कर ली है तो हम वहां से जा सकते हैं। धन्यवाद!

तकनीकी रूप से यह एपीआई प्रस्ताव प्रश्न नहीं है। निर्णय के लिए एपीआई अनुमोदन की आवश्यकता नहीं होगी। हालांकि, मैं मानता हूं कि अंतर को कैसे उजागर किया जाए, इस पर हमें गठबंधन किया जाना चाहिए - कुछ चर्चा होने की संभावना है।
मुझे यह उम्मीद नहीं है कि कार्यान्वयन में विकल्प एक दूसरे से बहुत अधिक भिन्न होते हैं - यदि समुदाय मदद करना चाहता है, तो किसी भी विकल्प के कार्यान्वयन से हमें वहां 98% मिलेगा (यह मानते हुए कि अपवाद एक जगह से फेंका गया है और हो सकता है [1]-[3] ऊपर सूचीबद्ध विकल्पों के अनुकूल होने के लिए बाद में आसानी से बदल दिया गया)।

नमस्ते! हमने हाल ही में इस मुद्दे को भी मारा। बस उत्सुक अगर यह अभी भी आपके रडार पर 3.0 के लिए है?

हां, यह अभी भी हमारी 3.0 सूची में है - मैं इसे अभी भी 90% मौका दूंगा कि इसे 3.0 में संबोधित किया जाएगा।

मैं आज इस पर भागा। मैंने एचटीपी क्लाइंट पर टाइमआउट सेट किया है और यह मुझे यह देता है:

{System.Threading.Tasks.TaskCanceledException: A task was canceled.}
CancellationRequested = true

मैं दूसरों से सहमत हूं कि यह भ्रमित करने वाला है क्योंकि इसमें टाइमआउट का मुद्दा नहीं है।

उम्म, ठीक है, मैं थोड़ा उलझन में हूँ। ऐसा लगता है कि इस थ्रेड में हर कोई कह रहा है कि HTTP टाइमआउट TaskCanceledException फेंकता है लेकिन मुझे वह नहीं मिल रहा है ... मुझे .NET कोर 2.1 में OperationCanceledException मिल रहा है ...

यदि आप टाइमआउट के लिए ऑपरेशन रद्द किए गए अपवाद को फेंकना चाहते हैं तो ठीक है, मैं उसके आसपास काम कर सकता हूं, लेकिन मैंने बस यह पता लगाने की कोशिश में घंटों बिताए कि बिल्ली क्या चल रही थी क्योंकि यह ठीक से दस्तावेज नहीं है:

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.sendasync

यह स्पष्ट रूप से बताता है कि टाइमआउट के लिए HttpRequestException फेंका गया है ...

कार्य रद्द अपवाद ऑपरेशन रद्द अपवाद से निकला है।

@stephentoub हां, लेकिन मुझे TaskCanceledException नहीं मिल रहा है, मुझे OperationCanceledException मिल रहा है।

जैसा कि, एक कैच ब्लॉक जो TaskCanceledException को पकड़ता है वह अपवाद नहीं पकड़ता है, इसे विशेष रूप से OperationCanceledException के लिए कैच ब्लॉक की आवश्यकता होती है।

अब मैं विशेष रूप से अपवाद के प्रकार पर फ़िल्टर करके HTTP टाइमआउट के लिए परीक्षण कर रहा हूं, और जिस तरह से मुझे पता है कि यह एक टाइमआउट है यदि यह TaskCanceledException नहीं है:

```सी#
कोशिश करो {
का उपयोग कर (var प्रतिक्रिया = प्रतीक्षा s_httpClient.SendAsync (अनुरोध, _updateCancellationSource.Token)। ConfigureAwait (गलत))
वापसी (int) प्रतिक्रिया। स्थिति कोड <400;
}
पकड़ें (ऑपरेशन रद्द अपवाद पूर्व) जब (उदा। गेट टाइप ()! = टाइपऑफ (टास्क रद्द अपवाद)) {
// HTTP टाइमआउट
विवरण झूठा है;
}
पकड़ें (HttpRequestException) {
विवरण झूठा है;
}

or alternatively this works as well, which might be better:

```c#
            try {
                using (var response = await s_httpClient.SendAsync(request, _updateCancellationSource.Token).ConfigureAwait(false))
                    return (int)response.StatusCode < 400;
            }
            catch (OperationCanceledException ex) when (ex.GetType() == typeof(OperationCanceledException)) {
                // HTTP timeout
                return false;
            }
            catch (HttpRequestException) {
                return false;
            }

उम्म, ठीक है, मैं थोड़ा उलझन में हूँ। ऐसा लगता है कि इस थ्रेड में हर कोई कह रहा है कि HTTP टाइमआउट TaskCanceledException फेंकता है लेकिन मुझे वह नहीं मिल रहा है ... मुझे .NET कोर 2.1 में OperationCanceledException मिल रहा है ...

यदि आप टाइमआउट के लिए ऑपरेशन रद्द किए गए अपवाद को फेंकना चाहते हैं तो ठीक है, मैं उसके आसपास काम कर सकता हूं, लेकिन मैंने बस यह पता लगाने की कोशिश में घंटों बिताए कि बिल्ली क्या चल रही थी क्योंकि यह ठीक से दस्तावेज नहीं है:

https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.sendasync

यह स्पष्ट रूप से बताता है कि टाइमआउट के लिए HttpRequestException फेंका गया है ...

क्या आपने पूरे धागे के माध्यम से पढ़ा है क्योंकि वास्तव में कई प्रतिक्रियाएं हैं जहां ऑपरेशन रद्द किए गए एक्सेप्शन का संदर्भ दिया गया है, जिसमें कोड उदाहरण मैंने देखा है जो टाइमआउट को स्पष्ट रूप से संभालने के लिए एक तरीका दिखाता है (जितना साफ नहीं है, लेकिन यह एक तरीका है)।

@ होब्रे हाँ मेरे पास है - आपको क्या लगता है कि मैंने नहीं किया? यह अभी भी यह नहीं बताता है कि इस धागे में कितने लोगों को टाइमआउट पर TaskCanceledException मिल रहा है, लेकिन मैं नहीं हूं।

मैंने आपका कोड उदाहरण भी देखा लेकिन दुर्भाग्य से इसमें दौड़ की स्थिति है कि मुझे विश्वास नहीं है कि आपने माना है। कोड पोस्ट किया गया है जिसका मैं उपयोग कर रहा हूं इस समस्या से बचाता है और रद्दीकरण टोकन तक पहुंच की आवश्यकता नहीं है, जो महत्वपूर्ण हो सकता है यदि आप टाइमआउट को और ऊपर की ओर पकड़ने की कोशिश कर रहे हैं।

@mikernet शायद शब्दों ने मुझे फेंक दिया। आप सही कह रहे हैं कि मैंने संभावित दौड़ की स्थिति पर विचार नहीं किया था। मुझे एहसास है कि यह एक बढ़िया समाधान नहीं है, लेकिन अगर आप यह बताना चाहते हैं कि मैंने क्या अनदेखा किया है, तो मैं इसे सुनना चाहता हूं।

एक बात मैंने देखी है कि आपको जो सटीक अपवाद मिलता है वह इस बात पर निर्भर करता है कि नियंत्रक बनाम मिडलवेयर आमंत्रण में टाइमआउट या रद्दीकरण होता है या नहीं। एक मिडलवेयर आमंत्रण के अंदर ऐसा लगता है कि यह सिर्फ TaskCanceledException है। दुर्भाग्य से मेरे पास यह समझने के लिए .NET कोर कोड पुस्तकालयों के माध्यम से खोदने का समय नहीं है, लेकिन यह कुछ ऐसा है जिसे मैंने देखा है।

@ होब्रे हाहा हाँ - क्षमा करें, मेरा मतलब दौड़ की स्थिति के बारे में गूढ़ होने का नहीं था, मैं बस अपने फोन पर था जब मैं उस अंतिम संदेश को टाइप कर रहा था जिससे व्याख्या करना मुश्किल हो गया।

आपके समाधान में दौड़ की स्थिति तब होती है जब HttpClient टाइमआउट और उस बिंदु के बीच कार्य रद्दीकरण शुरू किया जाता है जहां आप रद्दीकरण टोकन रद्दीकरण स्थिति की जांच करते हैं। मेरी स्थिति में मुझे बुलबुले को बनाए रखने के लिए एक कार्य रद्दीकरण अपवाद की आवश्यकता है ताकि अपस्ट्रीम कोड उपयोगकर्ता रद्दीकरण का पता लगा सके, इस प्रकार मुझे अपवाद को पकड़ने में सक्षम होने की आवश्यकता है यदि यह वास्तव में टाइमआउट है - यही कारण है कि मैं when का उपयोग कर रहा हूं पकड़ को छानने के लिए। टोकन की जाँच के अपने समाधान का उपयोग करने के परिणामस्वरूप फ़िल्टर को पास करने और बुदबुदाने और प्रोग्राम को क्रैश करने वाला $# OperationCanceledException 2$#$ हो सकता है, क्योंकि कोई व्यक्ति ऑपरेशन अपस्ट्रीम को रद्द करने की उम्मीद करेगा TaskCanceledException फेंके जाने की, नहीं एक OperationCanceledException ।

यदि HttpClient विधि को कॉल करने वाला कोड टाइमआउट और कार्य रद्दीकरण दोनों को संभालने के लिए माना जाता है तो स्थिति के आधार पर दौड़ की स्थिति होने पर टाइमआउट और उपयोगकर्ता रद्दीकरण के बीच भेद आपके लिए महत्वपूर्ण नहीं हो सकता है ... लेकिन अगर आप पुस्तकालय स्तर कोड लिख रहे हैं और कार्य रद्दीकरण बुलबुले को उच्च स्तर पर संभालने की आवश्यकता है तो इससे निश्चित रूप से फर्क पड़ता है।

यदि आप जो कह रहे हैं वह सत्य है और कॉलिंग संदर्भ के आधार पर टाइमआउट विभिन्न अपवाद प्रकार फेंकते हैं तो यह निश्चित रूप से मेरे लिए एक समस्या की तरह लगता है जिसे संबोधित करने की आवश्यकता है। ऐसा कोई तरीका नहीं है जो इच्छित व्यवहार हो या होना चाहिए।

संभावित दौड़ की स्थिति पर दिलचस्प। मैंने यह नहीं माना था। सौभाग्य से, मेरे उपयोग के मामले में यह बहुत अधिक समस्या नहीं होगी।

जहां तक ​​​​अपवाद भिन्नताएं हैं, मुझे यह देखने के लिए मिडलवेयर को कम करने के लिए कुछ समय खोजने की आवश्यकता है कि क्या यह डिबगिंग के दौरान मैंने कुछ बार देखा है या नहीं। बेवकूफ क्रोम ऑम्निबॉक्स प्रीलोड कॉल वह जगह है जहां मैंने इसे अपने मिडलवेयर में देखा है जब समय सही रहा है। मुझे लगता है कि मैं इसे एक या दूसरे तरीके से निश्चित रूप से साबित करने के लिए एक सरल उदाहरण बना सकता हूं।

मैं अभी भी स्पष्ट नहीं हूं कि सही कामकाज क्या होना चाहिए।

मेरा समाधान उन परिस्थितियों में सबसे सही है जहां http टाइमआउट ऑपरेशन रद्द अपवाद फेंक देते हैं। मैं उस स्थिति को पुन: उत्पन्न नहीं कर सकता जहां टास्क रद्द अपवाद फेंक दिया गया है और किसी ने उस व्यवहार को पुन: उत्पन्न करने का कोई तरीका प्रदान नहीं किया है, इसलिए मैं कहता हूं कि अपने पर्यावरण का परीक्षण करें और यदि यह मेरा मेल खाता है तो यह सही समाधान है।

यदि कुछ निष्पादन संदर्भों में एक कार्य रद्द किया गया अपवाद फेंक दिया गया है तो मेरा समाधान उन संदर्भों के लिए सामान्य उद्देश्य समाधान के रूप में विफल रहता है और प्रस्तावित अन्य समाधान "सर्वश्रेष्ठ" समाधान है लेकिन इसमें दौड़ की स्थिति शामिल है जो आपकी स्थिति के लिए महत्वपूर्ण हो सकती है या नहीं, वह है आप मूल्यांकन करने के लिए।

मुझे किसी ऐसे व्यक्ति से अधिक जानकारी सुनना अच्छा लगेगा जो दावा कर रहा है कि उन्हें टास्क रद्द किए गए अपवाद मिल रहे हैं क्योंकि यह स्पष्ट रूप से एक बड़ी बग होगी। मुझे कुछ संदेह है कि वास्तव में ऐसा हो रहा है।

@mikernet चाहे TaskCanceledException या OperationCanceledException फेंका गया हो, काफी हद तक अप्रासंगिक है। यह एक कार्यान्वयन विवरण है जिस पर आपको भरोसा नहीं करना चाहिए। आप क्या कर सकते हैं OperationException (जो TaskCanceledException को भी पकड़ लेगा) को पकड़ सकता है, और जांचें कि क्या आपके द्वारा पारित रद्दीकरण टोकन रद्द कर दिया गया है, जैसा कि होब्रे की टिप्पणी (https://github.com/) में वर्णित है। dotnet/corefx/issues/20296#issuecomment-449510983)।

@thomaslevesque मैंने पहले ही पता कर लिया है कि यह दृष्टिकोण एक समस्या क्यों है। इसे संबोधित किए बिना, आपकी टिप्पणी बहुत उपयोगी नहीं है - मेरे द्वारा वर्णित समस्या को संबोधित किए बिना रूपांतरण में शामिल होने से पहले यह केवल बयानों को फिर से दोहरा रहा है।

"यह एक कार्यान्वयन विवरण है" के लिए - हाँ यह है, लेकिन दुर्भाग्य से मुझे इस पर भरोसा करना है क्योंकि अन्यथा यह निर्धारित करने का कोई अच्छा तरीका नहीं है कि कार्य वास्तव में रद्द कर दिया गया था या समय समाप्त हो गया था। वर्णित दौड़ की स्थिति से बचने के लिए उन दो परिदृश्यों में से कौन सा अपवाद हुआ, यह निर्धारित करने का 100% तरीका होना चाहिए। OperationCanceledException इस वजह से सिर्फ एक खराब विकल्प है ... ढांचे में पहले से ही एक TimeoutException है जो एक बेहतर उम्मीदवार बनाता है।

अतुल्यकालिक कार्यों के लिए अपवादों को किसी अन्य ऑब्जेक्ट में डेटा की जाँच पर निर्भर नहीं होना चाहिए जिसे अपवाद के कारण को निर्धारित करने के लिए एसिंक्रोनस रूप से संशोधित किया जा सकता है यदि एक सामान्य उपयोग मामला अपवाद के कारण के आधार पर एक शाखा निर्णय लेने के लिए है। वह दौड़ की स्थिति की समस्याओं के लिए भीख माँग रहा है।

साथ ही, अपवाद प्रकार के कार्यान्वयन विवरण के संदर्भ में ... मुझे नहीं लगता कि यह अपवादों के लिए सच है, कम से कम अच्छी तरह से स्थापित .NET दस्तावेज़ीकरण प्रथाओं के संदर्भ में नहीं। .NET फ्रेमवर्क में एक अन्य उदाहरण का नाम दें जहां प्रलेखन कहता है "जब Y होता है तो अपवाद X फेंकता है" और फ्रेमवर्क वास्तव में उस अपवाद के सार्वजनिक रूप से सुलभ उपवर्ग को फेंकता है, अकेले सार्वजनिक रूप से सुलभ उपवर्ग को पूरी तरह से अलग अपवाद मामले के लिए उपयोग किया जाता है एक ही तरीका ! यह सिर्फ खराब फॉर्म की तरह लगता है और मैंने अपने 15 वर्षों के .NET प्रोग्रामिंग में इससे पहले कभी भी इसमें भाग नहीं लिया है।

भले ही, TaskCanceledException को उपयोगकर्ता द्वारा शुरू किए गए कार्य रद्द करने के लिए आरक्षित किया जाना चाहिए, न कि टाइमआउट के लिए - जैसा कि मैंने कहा, हमारे पास इसके लिए पहले से ही एक अपवाद है। पुस्तकालयों को किसी भी आंतरिक कार्य रद्दीकरण को कैप्चर करना चाहिए और अधिक उपयुक्त अपवादों को फेंकना चाहिए। कार्य रद्दीकरण के लिए अपवाद हैंडलर जो कार्य रद्दीकरण टोकन के साथ शुरू किए गए थे, उन्हें अन्य असंबंधित समस्याओं से निपटने के लिए जिम्मेदार नहीं होना चाहिए जो एसिंक्स ऑपरेशन के दौरान हो सकते हैं।

@mikernet क्षमा करें, मैंने चर्चा के उस हिस्से को याद किया। हां, एक दौड़ की स्थिति है जिसके बारे में मैंने नहीं सोचा था। लेकिन यह उतनी बड़ी समस्या नहीं हो सकती जितनी लगती है... दौड़ की स्थिति तब होती है जब रद्दीकरण टोकन समयबाह्य होने के बाद संकेत दिया जाता है, लेकिन इससे पहले कि आप टोकन की स्थिति की जांच करें, है ना? इस मामले में, यह वास्तव में कोई फर्क नहीं पड़ता कि अगर ऑपरेशन को रद्द किया जा रहा है तो टाइमआउट हुआ। तो आप एक OperationCanceledException बबल अप होने देंगे, जिससे कॉल करने वाले को विश्वास हो जाएगा कि ऑपरेशन सफलतापूर्वक रद्द कर दिया गया था, जो कि एक झूठ है क्योंकि वास्तव में एक टाइमआउट हुआ था, लेकिन यह कॉल करने वाले के लिए कोई मायने नहीं रखता, क्योंकि वे चाहते थे वैसे भी ऑपरेशन को निरस्त करें।

वर्णित दौड़ की स्थिति से बचने के लिए उन दो परिदृश्यों में से कौन सा अपवाद हुआ, यह निर्धारित करने का 100% तरीका होना चाहिए। OperationCanceledException इस वजह से सिर्फ एक खराब विकल्प है ... ढांचे में पहले से ही एक TimeoutException है जो एक बेहतर उम्मीदवार बनाता है।

मैं इससे पूरी तरह सहमत हूं, वर्तमान व्यवहार स्पष्ट रूप से गलत है। मेरी राय में इसे ठीक करने का सबसे अच्छा विकल्प @karelz की टिप्पणी से विकल्प 1 है। हां, यह एक ब्रेकिंग बदलाव है, लेकिन मुझे संदेह है कि अधिकांश कोड बेस इस परिदृश्य को वैसे भी सही तरीके से नहीं संभाल रहे हैं, इसलिए यह चीजों को और खराब नहीं करेगा।

@thomaslevesque ठीक है हाँ, लेकिन मैंने इसे संबोधित किया। यह कुछ अनुप्रयोगों के लिए महत्वपूर्ण हो भी सकता है और नहीं भी। हालांकि मेरे में है। मेरी लाइब्रेरी विधि का उपयोगकर्ता किसी कार्य को रद्द करते समय OperationCanceledException की अपेक्षा नहीं कर रहा है - वे TaskCanceledException की अपेक्षा कर रहे हैं और वे इसे पकड़ने और "सुरक्षित" होने में सक्षम होना चाहिए। अगर मैं रद्दीकरण टोकन की जांच करता हूं, तो देखें कि इसे रद्द कर दिया गया था और अपवाद को पास कर दिया गया था, तो मैंने अभी एक अपवाद पारित किया है जो उनके हैंडलर द्वारा पकड़ा नहीं जाएगा और प्रोग्राम को क्रैश कर देगा। मेरी विधि टाइमआउट पर फेंकने वाली नहीं है।

निश्चित रूप से, इसके आस-पास के तरीके हैं ... मैं बस एक नया लपेटा हुआ TaskCanceledException फेंक सकता हूं लेकिन फिर मैं शीर्ष स्तर का स्टैक ट्रेस खो देता हूं, और HTTP टाइमआउट को मेरी सेवा में कार्य रद्द करने की तुलना में बहुत अलग तरीके से व्यवहार किया जाता है - HTTP टाइमआउट जाओ एक लंबे समय के लिए कैश में, जबकि कार्य रद्द नहीं होगा। मैं दौड़ की स्थिति के कारण वास्तविक समयबाह्य कैशिंग को याद नहीं करना चाहता।

मुझे लगता है कि मैं OperationCanceledException पकड़ सकता हूं और रद्दीकरण टोकन की जांच कर सकता हूं - यदि इसे रद्द कर दिया गया है तो यह सुनिश्चित करने के लिए अपवाद के प्रकार की भी जांच करें कि यह पूरे प्रोग्राम क्रैशिंग चीज़ से बचने के लिए पुनर्स्थापित करने से पहले TaskCanceledException है। यदि उन शर्तों में से कोई भी गलत है तो यह एक टाइमआउट होना चाहिए। उस मामले में केवल समस्या बची है, वह दौड़ की स्थिति है जो सूक्ष्म है, लेकिन जब आपके पास प्रति मिनट हजारों HTTP अनुरोध होते हैं, तो एक भारी भरी हुई सेवा पर टाइट टाइमआउट सेट के साथ ऐसा होता है।

किसी भी तरह से हैकी है और जैसा कि आपने संकेत दिया है किसी भी तरह से हल किया जाना चाहिए।

(दौड़ की स्थिति केवल उन वातावरणों में होगी जहां TaskCanceledException को OperationCanceledException के बजाय फेंक दिया जाता है, जहां कहीं भी हो, लेकिन कम से कम समाधान एक अप्रत्याशित अपवाद प्रकार को बुदबुदाने से सुरक्षित है और नहीं यदि कार्यान्वयन विवरण में परिवर्तन होता है, तब भी यथोचित रूप से अच्छी तरह से काम करने के लिए कार्यान्वयन विवरण पर भरोसा करते हैं)।

http टाइमआउट के मामले में HttpClient द्वारा फेंका गया टाइमआउट अपवाद सामान्य System.TimeoutException के बजाय System.Net.HttpRequestException (या वंशज?) प्रकार का नहीं होना चाहिए? उदाहरण के लिए, अच्छा पुराना WebClient एक Status संपत्ति के साथ WebException $ फेंकता है जिसे WebExceptionStatus.Timeout पर सेट किया जा सकता है।

अफसोस की बात है कि हम इसे 3.0 के लिए पूरा नहीं कर पाएंगे। भविष्य की ओर बढ़ रहा है।
यह अभी भी हमारे बैकलॉग के शीर्ष पर है, लेकिन वास्तविक रूप से हम इसे 3.0 के लिए नहीं कर पाएंगे :(।

@karelz ओह नहीं :(

मुझे उपरोक्त टिप्पणियों के समूह में वास्तव में क्या हो रहा है, इस पर नज़र रखने में कठिनाई हो रही है, संदर्भ के आधार पर कार्य रद्दीकरण अपवाद और ऑपरेशन रद्द किए गए अपवाद प्राप्त करने के बीच मतभेदों की रिपोर्ट करने वाले लोगों के साथ, क्या एमएसएफटी से कोई भी इसे प्रकाशित कर सकता है?

@mikernet की इस टिप्पणी को लाइक करें:

जैसा कि, एक कैच ब्लॉक जो टास्ककैंसल्ड एक्सेप्शन को पकड़ता है, अपवाद को नहीं पकड़ता है, इसे विशेष रूप से ऑपरेशन कैंसिल्ड एक्सेप्शन के लिए कैच ब्लॉक की आवश्यकता होती है।

cc @davidsh @stephentoub शायद?

कार्य रद्द अपवाद ऑपरेशन रद्द अपवाद से निकला है, और कुछ अतिरिक्त जानकारी रखता है। बस ऑपरेशन रद्द किए गए अपवाद को पकड़ें।

@karelz विकल्प 1 होगा जिसे आपने मूल रूप से पोस्ट किया था, बस इसे टाइमआउट अपवाद फेंक दिया, पूरी तरह से अप्राप्य हो?

StackExchange.Redis जैसी चीजें टाइमआउट अपवाद से प्राप्त अपवाद फेंकती हैं, इसलिए एचटीपी क्लाइंट के लिए टाइमआउट अपवाद को पकड़ना अच्छा होगा ...

मैं समझता हूं कि @stephentoub ने विरासत दी है, बस @mikernet से नीचे की यह टिप्पणी मेरे दिमाग को उड़ा रही है ... वह जिस व्यवहार का वर्णन करता है वह किसी प्रकार का बग होना चाहिए ?? लेकिन अगर सही है, तो फिक्स या वर्कअराउंड को प्रभावित करेगा ...

"एक कैच ब्लॉक जो टास्क रद्द किए गए अपवाद को पकड़ता है, अपवाद नहीं पकड़ता है, इसे विशेष रूप से ऑपरेशन रद्द किए गए अपवाद के लिए कैच ब्लॉक की आवश्यकता होती है"

या आप कह रहे हैं कि कुछ जगहों पर यह ऑपरेशनएक्स और अन्य जगहों को टास्कएक्स फेंकता है? जैसे शायद लोग एएसपी मिडलवेयर से कुछ आ रहे हैं और सोच रहे हैं कि यह एचटीपी क्लाइंट से है?

@mikernet की बस नीचे दी गई यह टिप्पणी मेरे दिमाग को उड़ा रही है ... वह जिस व्यवहार का वर्णन करता है वह किसी प्रकार का बग होना चाहिए ??

वह "आपके दिमाग को उड़ा रहा है" क्यों है? यदि अपवाद बी अपवाद ए से निकला है, तो बी के लिए एक कैच ब्लॉक एक अपवाद नहीं पकड़ेगा जो कि ठोस रूप से ए है, उदाहरण के लिए यदि मेरे पास ArgumentNullException के लिए कैच ब्लॉक है, तो यह "नया ArgumentException (...) फेंकें" नहीं पकड़ेगा।

या आप कह रहे हैं कि कुछ जगहों पर यह ऑपरेशनएक्स और अन्य जगहों को टास्कएक्स फेंकता है?

सही। सामान्य कोड में केवल OCE मान लेना चाहिए; जिस तरह से चीजें लिखी जाती हैं, कुछ कोड व्युत्पन्न टीसीई को फेंक सकते हैं, उदाहरण के लिए टास्ककंप्लीशनसोर्स के माध्यम से पूरा किया गया कार्य। ट्राईसेट रद्द किया गया एक टास्क रद्द किया गया अपवाद उत्पन्न करेगा।

धन्यवाद स्टीफन, धागे में चीजों की आवाज़ से कई लोग इस धारणा के तहत थे कि टास्कसीई को हर जगह फेंक दिया जा रहा था, जिससे मिकर्नेट द्वारा वर्णित व्यवहार का कोई मतलब नहीं होता ... अब जब आपने स्पष्ट किया है, तो यह उसका बनाता है अवलोकन तार्किक :)

@stephentoub , क्या यह मार्गदर्शन कहीं भी प्रलेखित है? पिंगिंग @guardrex

सामान्य कोड में केवल OCE मान लेना चाहिए ...

मैं इन दिनों ASP.NET दस्तावेज़ सेट पर काम करता हूं। डॉटनेट/दस्तावेज़ बिल्लियों के लिए एक मुद्दा खोलें ...

https://github.com/dotnet/docs/issues

क्या इस बातचीत को फिर से शुरू करना संभव है जहां @karelz और @davidsh के साथ कुछ ठोस प्रस्ताव थे ? ऐसा लगता है कि एचटीपी क्लाइंट एपीआई मॉडल के स्वामित्व वाले किसी व्यक्ति को जाने की दिशा के बारे में निर्णय लेने की जरूरत है। शीर्ष-स्तरीय अपवादों के बारे में कुछ चर्चा हमेशा HttpRequestException (स्पष्ट रद्दीकरण के अलावा ??) होने के बारे में थी, जिसमें WebExceptionStatus के समान एक नई एनम संपत्ति शामिल करने के लिए HttpRequestion को संशोधित करने के लिए एक बड़े रिफ्लेक्टर के बारे में कुछ लंबी अवधि के प्रतीत होने वाले विषय के साथ मिश्रित किया गया था ...

ऐसा लगता है कि यह पूरा मुद्दा वास्तविक कोड परिवर्तन की आवश्यकता के सापेक्ष गिलहरी हो रहा है। क्या ऐसे अन्य लोग हैं जिनके पास एचटीपी क्लाइंट एपीआई मॉडल में हिस्सेदारी/स्वामित्व है जिन्हें कुछ निर्णय लेने के लिए लूप किया जाना चाहिए? धन्यवाद एक टन सब!

मुझे यहां एक ही समस्या हो रही है - हालांकि, cancellationToken.IsCancellationRequested true लौटा रहा है:

    public class TimeoutHandler : DelegatingHandler
    {
        protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
        {
            try
            {
                var response = await base.SendAsync(request, cancellationToken);
                response.EnsureSuccessStatusCode();

                return response;
            }
            catch (OperationCanceledException) when (!cancellationToken.IsCancellationRequested)
            {
                throw new TimeoutException("Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.");
            }
        }

मैं एक समयबाह्य मजबूर कर रहा हूँ। उठाया गया अपवाद TaskCancelledException है जिसमें IOException आंतरिक अपवाद के रूप में है:

System.Threading.Tasks.TaskCanceledException: The operation was canceled. ---> System.IO.IOException: Unable to read data from the transport connection: A operação de E/S foi anulada devido a uma saída de thread ou a uma requisição de aplicativo. ---> System.Net.Sockets.SocketException: A operação de E/S foi anulada devido a uma saída de thread ou a uma requisição de aplicativo
   --- End of inner exception stack trace ---
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.GetResult(Int16 token)
   at System.Net.Http.HttpConnection.FillAsync()
   at System.Net.Http.HttpConnection.ReadNextResponseHeaderLineAsync(Boolean foldedHeadersAllowed)
   at System.Threading.Tasks.ValueTask`1.get_Result()
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)

...

(अनुवादित अपवाद पाठ के लिए खेद है - जाहिर तौर पर किसी ने सोचा कि इसे .NET कोर में भी लाना एक अच्छा विचार होगा)

जैसा कि आप देख सकते हैं, मैं इस मुद्दे को हल करने के लिए IsCancellationRequest की जांच करने की उम्मीद कर रहा था जैसा कि अन्य ने सुझाव दिया है, लेकिन टाइमआउट पर भी यह true लौटा रहा है।

वर्तमान में मैं यह जांचने के लिए टाइमर लागू करने की सोच रहा हूं कि कॉन्फ़िगर किया गया टाइमआउट बीत चुका है या नहीं। लेकिन, जाहिर है मैं मरना चाहता हूं यह एक भयानक समाधान है।

हाय @FelipeTaveira ,

आपका दृष्टिकोण काम नहीं करता है, क्योंकि रद्दीकरण को आपके TimeoutHandler के अपस्ट्रीम में HttpClient द्वारा ही नियंत्रित किया जाता है। आपके हैंडलर को एक रद्दीकरण टोकन प्राप्त होता है जिसे $#$3 Timeout HttpClient द्वारा रद्द कर दिया जाता है। इसलिए जांचना कि रद्दीकरण टोकन रद्द नहीं किया गया है, केवल उस कोड में काम करता है जो HttpClient को कॉल कर रहा है, न कि HttpClient द्वारा बुलाए गए कोड में।

इसे कस्टम हैंडलर के साथ काम करने का तरीका HttpClient के Timeout को Timeout.InfiniteTimeSpan पर सेट करके और अपने स्वयं के हैंडलर में टाइमआउट व्यवहार को नियंत्रित करके अक्षम करना है, जैसा कि इस लेख में दिखाया गया है ( यहां पूरा कोड)

@thomaslevesque ओह, धन्यवाद! मैंने आपके कोड के माध्यम से पढ़ा था और सोचा था कि हिस्सा प्रति-अनुरोध टाइमआउट कॉन्फ़िगरेशन का समर्थन करने के बारे में था और यह नहीं देखा था कि TimeoutException चीज़ का समर्थन करना भी आवश्यक था।

मुझे उम्मीद है कि भविष्य में इस पर ध्यान दिया जाएगा।

इसके लायक क्या है, मुझे भ्रमित होने के लिए टाइमआउट पर TaskCanceledException फेंका जा रहा है।

मैं प्रमाणित कर सकता हूं कि मेरी पिछली नौकरी में उत्पादन के मुद्दों से निपटने के दौरान TaskCanceledExceptions भ्रम का एक प्रमुख स्रोत था। हम आम तौर पर एचटीपी क्लाइंट को कॉल लपेटते हैं और जहां उपयुक्त हो टाइमआउट अपवाद फेंक देते हैं।

@eiriktsarpalis धन्यवाद। हम इसे 5.0 में संबोधित करने की योजना बना रहे हैं, इसलिए यदि आप चाहें तो उस समय सीमा में इसे उठा सकते हैं, अब जब आप हमारी टीम में शामिल हो गए हैं।

1 साल? .NET कोर की वह वादा की गई चपलता कहाँ है?

एक मुद्दे के आधार पर पूरे प्रोजेक्ट की चपलता को आंकना थोड़ा अनुचित है।
हां, यह थोड़ा शर्मनाक है, हमें अभी भी यह समस्या है, हालांकि, इसे ठीक करना मुश्किल है (संगत प्रभाव के साथ) और पहले (नेटवर्किंग में) निपटने के लिए केवल उच्च-प्राथमिक व्यावसायिक लक्ष्य थे - पूरे इतिहास में मील के पत्थर में बदलाव देखें इस मुद्दे की।

बीटीडब्ल्यू: कई अन्य ओएसएस परियोजनाओं की तरह, कोई एसएलए या ईटीए या कोई वादा नहीं है कि समस्या कब तय की जाएगी। सब कुछ प्राथमिकताओं, अन्य कार्य, कठिनाई और समस्या से निपटने में सक्षम विशेषज्ञों की संख्या पर निर्भर करता है।

एक मुद्दे के आधार पर पूरे प्रोजेक्ट की चपलता को आंकना थोड़ा अनुचित है।

खैर, यह एक ईमानदार सवाल था। दो साल हो चुके हैं और जब मैंने देखा कि यह एक और साल लेने वाला है तो मैं थोड़ा हैरान हुआ। हालांकि कोई अपराध नहीं . मुझे पता है कि इस मुद्दे को ठीक करने के लिए कुछ ऐसे प्रश्न थे जिनका उत्तर पहले देना था/हैं।

समझौतों की दुनिया में... मुझे यह पसंद नहीं है, लेकिन यहाँ एक और विकल्प है जिसे आप चबा सकते हैं:

हम TaskCanceledException फेंकना जारी रख सकते हैं, लेकिन इसके CancellationToken को एक संतरी मान पर सेट कर सकते हैं।

c# catch(TaskCanceledException ex) when(ex.CancellationToken == HttpClient.TimeoutToken) { }

और दूसरा: एक नया HttpTimeoutException फेंकें जो TaskCanceledException से निकला है।

और दूसरा: एक नया HttpTimeoutException फेंकें जो TaskCanceledException से निकला है।

मुझे लगता है कि इससे सभी चिंताओं का समाधान हो जाएगा। यह विशेष रूप से टाइमआउट को पकड़ना आसान बनाता है, और यह अभी भी एक TaskCanceledException है, इसलिए कोड जो वर्तमान में उस अपवाद को पकड़ता है वह भी नया पकड़ लेगा (कोई ब्रेकिंग परिवर्तन नहीं)।

और दूसरा: एक नया HttpTimeoutException फेंक दें जो टास्क रद्द किए गए अपवाद से निकला है।

यह बल्कि बदसूरत लगता है, लेकिन शायद एक अच्छा समझौता है।

और दूसरा: एक नया HttpTimeoutException फेंकें जो TaskCanceledException से निकला है।

मुझे लगता है कि इससे सभी चिंताओं का समाधान हो जाएगा। यह विशेष रूप से टाइमआउट को पकड़ना आसान बनाता है, और यह अभी भी एक TaskCanceledException है, इसलिए कोड जो वर्तमान में उस अपवाद को पकड़ता है वह भी नया पकड़ लेगा (कोई ब्रेकिंग परिवर्तन नहीं)।

ठीक है, वहाँ _could_ लोग इस तरह से कोड लिख रहे हैं:

try
{
  // ...
}
catch (Exception ex) when (ex.GetType() == typeof(TaskCanceledException))
{
}

तो यह तकनीकी रूप से एक महत्वपूर्ण बदलाव होगा।

इसके अलावा, मुझे लगता है कि यह दोनों दुनियाओं में सबसे खराब है। हमें अभी भी एक सामान्य TimeoutException एक ही समय में एक ब्रेकिंग परिवर्तन नहीं मिलेगा।

ऐसे लोग हो सकते हैं जो इस तरह से कोड लिख रहे हों, इसलिए यह तकनीकी रूप से एक महत्वपूर्ण बदलाव होगा

एफडब्ल्यूआईडब्ल्यू, लगभग हर परिवर्तन संभवतः टूट रहा है, इसलिए किसी भी चीज़ पर आगे बढ़ने के लिए किसी को कहीं न कहीं एक रेखा खींचनी होगी। Corefx में हम ब्रेकिंग के लिए अधिक व्युत्पन्न प्रकार को वापस करने या फेंकने पर विचार नहीं करते हैं।
https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/breaking-change-rules.md#exceptions

समझौतों की दुनिया में... मुझे यह पसंद नहीं है, लेकिन यहाँ एक और विकल्प है जिसे आप चबा सकते हैं:

हम TaskCanceledException फेंकना जारी रख सकते हैं, लेकिन इसके CancellationToken को एक संतरी मान पर सेट कर सकते हैं।

catch(TaskCanceledException ex) when(ex.CancellationToken == HttpClient.TimeoutToken)
{
}

मुझे यह वास्तव में पसंद है। ""बदसूरत"" होने के अलावा क्या इसका कोई और नुकसान है? टाइमआउट होने पर आज ex.CancellationToken क्या है?

""बदसूरत"" होने के अलावा क्या इसका कोई और नुकसान है?

किसी के लिए यह सोचना वास्तव में आसान होगा कि टाइमआउट टोकन को पास किया जा सकता है और टाइमआउट होने पर रद्दीकरण को संकेत देने के लिए उपयोग किया जाता है, क्योंकि यह वह डिज़ाइन है जो ऐसी चीजों के लिए कहीं और उपयोग किया जाता है।

मुझे यह वास्तव में पसंद है। ""बदसूरत"" होने के अलावा क्या इसका कोई और नुकसान है? टाइमआउट होने पर आज ex.CancellationToken क्या है?

यह एक विशिष्ट अपवाद प्रकार को पकड़ने की तुलना में बहुत कम सहज है, जिसका दस्तावेज़ीकरण में स्पष्ट रूप से उल्लेख किया जा सकता है।

मुझे OperationCanceledException और व्युत्पन्न प्रकारों पर विचार करने के लिए उपयोग किया जाता है ताकि एक बाधित निष्पादन को इंगित किया जा सके, न कि एप्लिकेशन त्रुटि। अपवाद HttpClient टाइमआउट पर फेंकता आमतौर पर एक त्रुटि है - एक HTTP एपीआई के लिए एक कॉल था, और यह अनुपलब्ध था। यह व्यवहार या तो उच्च स्तर पर अपवादों को संसाधित करते समय जटिलताओं की ओर ले जाता है, उदाहरण के लिए, ASP.NET कोर पाइपलाइन मिडलवेयर में, क्योंकि इस कोड को यह जानना है कि OperationCanceledException के दो स्वाद हैं, त्रुटि और त्रुटि नहीं, या यह आपको प्रत्येक HttpClient कॉल को थ्रो-कैच ब्लॉक में लपेटने के लिए बाध्य करता है।

और दूसरा: एक नया HttpTimeoutException फेंक दें जो टास्क रद्द किए गए अपवाद से निकला है।

यह बल्कि बदसूरत लगता है, लेकिन शायद एक अच्छा समझौता है।

क्या यह वास्तव में बदसूरत है, हालांकि डिजाइन की बाधाओं और पीछे की संगतता के विचारों को देखते हुए? मुझे नहीं पता कि इस सूत्र में किसी ने स्पष्ट रूप से बेहतर समाधान का प्रस्ताव दिया है जिसमें शून्य कमियां हैं (चाहे डिजाइन का उपयोग या शुद्धता आदि)

हम अपवाद प्रकार को बदलने के बजाय इसे और गहराई से देखना चाहते हैं। "हमने टाइमआउट कहाँ किया?" का एक लंबे समय से चल रहा मुद्दा भी है। - उदाहरण के लिए, बिना तार से टकराए समय-समय पर अनुरोध करना संभव है - जिसे हमें देखने की जरूरत है, और एक समाधान उस दिशा के अनुकूल होना चाहिए जो हम वहां जाते हैं।

हम अपवाद प्रकार को बदलने के बजाय इसे और गहराई से देखना चाहते हैं। "हमने टाइमआउट कहाँ किया?" का एक लंबे समय से चल रहा मुद्दा भी है। - उदाहरण के लिए, बिना तार से टकराए समय-समय पर अनुरोध करना संभव है - जिसे हमें देखने की जरूरत है, और एक समाधान उस दिशा के अनुकूल होना चाहिए जो हम वहां जाते हैं।

क्या यह वास्तव में कुछ ऐसा है जिसे आपको जानना आवश्यक है? मेरा मतलब है, क्या आप त्रुटि को अलग-अलग तरीके से संभालेंगे, इस पर निर्भर करते हुए कि यह समय समाप्त हो गया है? मेरे लिए, केवल यह जानना कि एक टाइमआउट हुआ आमतौर पर पर्याप्त होता है।
यदि आप और अधिक करना चाहते हैं तो मुझे कोई आपत्ति नहीं है, मैं नहीं चाहता कि यह परिवर्तन अतिरिक्त आवश्यकताओं के कारण .NET 5 ट्रेन से छूट जाए: पलक:

मुझे लगता है कि @scalablecory उठाया गया मुद्दा उल्लेखनीय है, लेकिन मैं मानता हूं कि इसे जल्द से जल्द ठीक करने में बाधा नहीं बननी चाहिए। आप टाइमआउट कारण का मूल्यांकन करने की अनुमति देने के लिए एक तंत्रवाद पर निर्णय ले सकते हैं लेकिन कृपया उसके लिए अपवाद समस्या को ठीक करने में देरी न करें ... आप बाद में अपवाद में हमेशा Reason संपत्ति जोड़ सकते हैं।

मैं @thomaslevesque से सहमत हूं; मैंने इसे पहले एक बड़ी समस्या के रूप में नहीं सुना है। यह कहाँ से आ रहा है?

क्या यह एक काफी विशिष्ट डिबगिंग केस है जहां थोड़ी स्पष्ट कार्रवाई की आवश्यकता के कारण खुदाई करना ठीक होगा, जबकि सामान्य डेवलपर के लिए उन्हें केवल एक ही चीज़ को संभालने के बारे में जानना/देखभाल करना होगा।

हम अपवाद प्रकार को बदलने के बजाय इसे और गहराई से देखना चाहते हैं। "हमने टाइमआउट कहाँ किया?" का एक लंबे समय से चल रहा मुद्दा भी है। - उदाहरण के लिए, बिना तार से टकराए समय-समय पर अनुरोध करना संभव है - जिसे हमें देखने की जरूरत है, और एक समाधान उस दिशा के अनुकूल होना चाहिए जो हम वहां जाते हैं।

मुझे लगता है कि यहां निहितार्थ यह है कि एचटीपी क्लाइंट फिक्सिंग चीजों के बजाय सही टाइमआउट अपवाद प्रकार को फेंकने के लिए प्रत्येक HttpMessageHandler की ज़िम्मेदारी होनी चाहिए।

मुझे लगता है कि यहां निहितार्थ यह है कि एचटीपी क्लाइंट फिक्सिंग चीजों के बजाय सही टाइमआउट अपवाद प्रकार को फेंकने के लिए प्रत्येक HttpMessageHandler की ज़िम्मेदारी होनी चाहिए।

मैं नहीं देखता कि आज परिभाषित अमूर्तता के साथ यह कैसे संभव है। HttpMessageHandler को HttpClient के टाइमआउट का कोई ज्ञान नहीं है; जहां तक ​​​​एक HttpMessageHandler का संबंध है, इसे सिर्फ एक रद्दीकरण टोकन दिया गया है, जिसमें किसी भी कारण से रद्दीकरण का अनुरोध किया जा सकता है, जिसमें कॉलर के रद्दीकरण टोकन को सिग्नल किया जा रहा है, HttpClient के रद्द करने के अनुरोध को कॉल किया जा रहा है, एचटीपी क्लाइंट का लागू टाइमआउट समाप्त हो रहा है, आदि।

क्या यह वास्तव में कुछ ऐसा है जिसे आपको जानना आवश्यक है? मेरा मतलब है, क्या आप त्रुटि को अलग-अलग तरीके से संभालेंगे, इस पर निर्भर करते हुए कि यह समय समाप्त हो गया है? मेरे लिए, केवल यह जानना कि एक टाइमआउट हुआ आमतौर पर पर्याप्त होता है।

यह जानना उपयोगी है कि सर्वर ने आपके अनुरोध को संसाधित किया है या नहीं। यह डायग्नोस्टिक्स के लिए भी बहुत अच्छा है - एक दूरस्थ सर्वर समय समाप्त नहीं होता है लेकिन क्लाइंट रिपोर्टिंग टाइमआउट एक निराशाजनक अनुभव है।

@davidsh में कुछ और अंतर्दृष्टि हो सकती है।

मैं @thomaslevesque से सहमत हूं; मैंने इसे पहले एक बड़ी समस्या के रूप में नहीं सुना है। यह कहाँ से आ रहा है?

हाल ही में एनसीएल की बैठक के दौरान यह मुद्दा उठाया गया था। यह हो सकता है कि हम तय करें कि यह चीजों को उजागर करने या देरी करने के लिए पर्याप्त महत्वपूर्ण नहीं है, लेकिन यह पहले एक त्वरित चर्चा के लायक है।

@ dotnet/ncl @stephentoub इसे बिस्तर पर डाल दें। हम जानते हैं कि हम जो कुछ भी करेंगे वह सूक्ष्म रूप से टूट जाएगा। यह कम से कम सबसे खराब विकल्प की तरह लगता है। मैं इसके साथ आगे बढ़ने का प्रस्ताव करता हूं:

एक नया HttpTimeoutException फेंकें जो TaskCanceledException से निकला है।

आपत्तियां?

एक नया HttpTimeoutException फेंकें जो टास्क रद्द किए गए अपवाद से निकला है।

हम इसे व्यवहार में कैसे करते हैं? इसका शायद मतलब है कि हमें अपना कोड साफ़ करना होगा और उन सभी स्थानों को ढूंढना होगा जो रद्दीकरण टोकन कहते हैं। थ्रोइफ कैंसेलेशन अनुरोधित और इसके बजाय इसे परिवर्तित करें:

c# if (token.IsCancellationRequested) throw new HttpTimeoutException(EXTRASTUFF, token);

साथ ही एक स्पष्ट स्थान जिसे हम वास्तव में OperationCancelledException भी कॉल कर सकते हैं।

क्या कोई विकल्प है जिसके लिए वैसे भी उस सभी संबंधित कोड पर जाने की आवश्यकता नहीं है?

क्या कोई विकल्प है जिसके लिए वैसे भी उस सभी संबंधित कोड पर जाने की आवश्यकता नहीं है?

शायद नहीं, लेकिन ऐसे स्थान हो सकते हैं जिन्हें हम नियंत्रित नहीं करते हैं (वास्तव में अभी तक निश्चित नहीं हैं) और इसलिए हमें संभावित रूप से एक यादृच्छिक कार्य रद्दीकरण/ऑपरेशन रद्द किए गए अपवाद को पकड़ने और नए एचटीपीटाइमआउट अपवाद को पुनर्स्थापित करने की आवश्यकता होगी।

इसका शायद मतलब है कि हमें अपना कोड साफ़ करना होगा और उन सभी स्थानों को ढूंढना होगा जो रद्दीकरण टोकन कहते हैं। थ्रोइफ कैंसेलेशन अनुरोधित और इसके बजाय इसे परिवर्तित करें:

क्या कोई विकल्प है जिसके लिए वैसे भी उस सभी संबंधित कोड पर जाने की आवश्यकता नहीं है?

बिल्कुल नहीं।

जहां तक ​​संचालकों का संबंध है, उन्हें केवल एक रद्दीकरण टोकन प्राप्त होता है: वे नहीं जानते और परवाह नहीं करते कि वह टोकन कहां से आया, किसने इसे बनाया, या इसे रद्द करने का अनुरोध क्यों किया जा सकता है। वे केवल इतना जानते हैं कि किसी बिंदु पर रद्द करने का अनुरोध किया जा सकता है, और वे प्रतिक्रिया में रद्दीकरण अपवाद फेंक देते हैं। तो, यहाँ हैंडलर्स में करने के लिए कुछ नहीं है।

यह एचटीपी क्लाइंट ही है जो प्रासंगिक रद्दीकरण टोकन स्रोत बना रहा है और उस पर टाइमआउट सेट कर रहा है:
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L488
टाइमआउट पूरी तरह से एचटीपी क्लाइंट का आविष्कार है, और केवल यह जानता है कि क्या वह रद्दीकरण अपवाद का इलाज करना चाहता है जो विशेष रूप से उभरा है।

इसका मतलब है कि उपरोक्त संदर्भित कोड को टाइमआउट को अलग से ट्रैक करने के लिए अलग से, या तो एक अलग रद्दीकरण टोकन स्रोत के रूप में, या अधिक संभावना है कि टाइमआउट तर्क को अपने आप से संभालने की आवश्यकता होगी, और सीटीएस को रद्द करने के अलावा, एक ध्वज भी सेट कर सकता है जो यह कर सकता है फिर जाँच भी करें। यह संभवतः नॉन-पे-फॉर-प्ले होने वाला है, इसमें हम यहां अतिरिक्त आवंटन जोड़ रहे हैं, लेकिन एक कोड के नजरिए से यह अपेक्षाकृत सरल है।

फिर HttpClient जैसे स्थानों में:
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L536 -L541
तथा
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L562 -L566
जब यह अपवाद पकड़ता है, तो यह देखने के लिए कि टाइमआउट समाप्त हो गया है या नहीं, यह देखने के लिए विशेष-केस रद्दीकरण की आवश्यकता होगी, और यदि ऐसा होता है, तो मान लें कि यह रद्दीकरण का कारण था और वांछित प्रकार का एक नया अपवाद फेंक दें।

यह देखने के लिए कि क्या टाइमआउट समाप्त हो गया है, यह जांचने के लिए विशेष-केस रद्दीकरण की आवश्यकता होगी, और यदि यह था, तो मान लें कि यह रद्दीकरण का कारण था और वांछित प्रकार का एक नया अपवाद फेंक दें।

यह कैसे काम करता है यदि HttpClient.Timeout संपत्ति शामिल नहीं है? शायद यह "अनंत" पर सेट है। रद्दीकरण टोकन के बारे में क्या सीधे एचटीपी क्लाइंट एपीआई (GetAsync, SendAync इत्यादि) में पारित किया गया है? मुझे लगता है कि वही काम करेगा?

यह कैसे काम करता है यदि HttpClient.Timeout संपत्ति शामिल नहीं है?

मैं इस प्रश्न को समझ नहीं पा रहा हूं... यहां केवल यही टाइमआउट है जिसके बारे में हम बात कर रहे हैं। अगर इसे अनंत पर सेट किया जाता है, तो इस टाइमआउट के कारण कभी भी रद्दीकरण नहीं होगा, और करने के लिए कुछ नहीं होगा। हम पहले से ही स्पेशल-केस टाइमआउट == अनंत हैं और आगे भी जारी रखेंगे:
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L481

रद्दीकरण टोकन के बारे में क्या सीधे एचटीपी क्लाइंट एपीआई (GetAsync, SendAync इत्यादि) में पारित किया गया है? मुझे लगता है कि वही काम करेगा?

हम अपने स्वयं के निर्माण के साथ जो भी टोकन पारित करते हैं, उसे जोड़ते हैं:
https://github.com/dotnet/corefx/blob/bdd33976fe3713cc3e78b83cf2a1176c70b793be/src/System.Net.Http/src/System/Net/Http/HttpClient.cs#L485
जैसा कि मेरी पिछली टिप्पणियों में बताया गया है, हम HttpClient.Timeout के अपने स्वयं के संचालन को ट्रैक करेंगे। यदि कॉलर एक टोकन में पास करना चुनता है जिसे उन्होंने टाइमआउट के साथ कॉन्फ़िगर किया है, तो उसका इलाज करना विशेष रूप से उनके ऊपर है: जहां तक ​​​​हमारा संबंध है, यह केवल एक रद्दीकरण अनुरोध है।

आपत्तियां?

एक नया व्युत्पन्न अपवाद प्रकार क्यों पेश करें जो मौजूदा टाइमआउट अपवाद के साथ "प्रतिस्पर्धा" करता है, कहें, एक रद्दीकरण अपवाद फेंकना जो टाइमआउट अपवाद को आंतरिक अपवाद के रूप में लपेटता है? यदि लक्ष्य किसी उपभोक्ता को प्रोग्रामेटिक रूप से यह निर्धारित करने में सक्षम बनाना है कि क्या रद्दीकरण एक टाइमआउट के कारण था, तो क्या यह पर्याप्त होगा? ऐसा लगता है कि नए सतह क्षेत्र की आवश्यकता के बिना, एक ही जानकारी को संवाद करना प्रतीत होता है।

एक नया व्युत्पन्न अपवाद प्रकार क्यों पेश करें जो मौजूदा टाइमआउट अपवाद के साथ "प्रतिस्पर्धा" करता है, कहने के बजाय, एक रद्दीकरण अपवाद फेंकना जो टाइमआउट अपवाद को आंतरिक अपवाद के रूप में लपेटता है

सुविधा के लिए, ज्यादातर। लिखना आसान और अधिक सहज है

catch(HttpTimeoutException)

से

catch(OperationCanceledException ex) when (ex.InnerException is TimeoutException)

कहा जा रहा है, मेरे द्वारा किसी भी तरह से ठीक है, जब तक कि टाइमआउट की पहचान करना उचित रूप से आसान हो।

कहें, एक रद्दीकरण अपवाद फेंकना जो टाइमआउट अपवाद को आंतरिक अपवाद के रूप में लपेटता है?

मुझे लगता है कि यह एक अच्छा समझौता है। यह अपवाद लॉग को स्पष्ट करने में मदद करेगा, जो इस प्रकार के टाइमआउट से निपटने के दौरान मेरी झुंझलाहट का प्राथमिक स्रोत था। यह शायद इस तथ्य को भी बेहतर ढंग से संप्रेषित करता है कि यह एचटीपी क्लाइंट है जो अंतर्निहित हैंडलर द्वारा उठाए गए टाइमआउट के बजाय अनुरोध को रद्द कर रहा है। इसके अलावा, कोई ब्रेकिंग परिवर्तन नहीं।

ट्राइएज:

• हम लॉगिंग/डायग्नोस्टिक्स के लिए एक संदेश के साथ InnerException के TimeoutException के लिए इस परिदृश्य को अपडेट करेंगे जो आसानी से रद्दीकरण को टाइमआउट ट्रिगरिंग के कारण होने के रूप में अलग करता है।
• हम उन तरीकों पर मार्गदर्शन के साथ दस्तावेज़ों को अपडेट करेंगे, जो रद्दीकरण में अंतर करने के लिए प्रोग्रामिक रूप से निरीक्षण कर सकते हैं: TimeoutException के लिए जाँच करना, अनंत Timeout का उपयोग करना और एक टाइमआउट अवधि के साथ CancellationToken पास करना आदि।

हम मानते हैं कि यहां किसी भी समाधान में कुछ समझौता शामिल है, और विश्वास है कि यह मौजूदा कोड के साथ संगतता का एक अच्छा स्तर प्रदान करेगा।

एक नया व्युत्पन्न अपवाद प्रकार क्यों पेश करें जो मौजूदा टाइमआउट अपवाद के साथ "प्रतिस्पर्धा" करता है, कहने के बजाय, एक रद्दीकरण अपवाद फेंकना जो टाइमआउट अपवाद को आंतरिक अपवाद के रूप में लपेटता है

सुविधा के लिए, ज्यादातर। लिखना आसान और अधिक सहज है

catch(HttpTimeoutException)

से

catch(OperationCanceledException ex) when (ex.InnerException is TimeoutException)

कहा जा रहा है, मेरे द्वारा किसी भी तरह से ठीक है, जब तक कि टाइमआउट की पहचान करना उचित रूप से आसान हो।

@scalablecory मैं निराश हूं कि मैंने कुछ घंटों तक चर्चा को याद किया है - सामान्य एलओबी .NET डेवलपर्स के साथ इस प्रकार की चीजों को संप्रेषित करने का मेरा अनुभव यह है कि व्युत्पन्न एचटीपीटाइमआउट अपवाद को पकड़ना लोगों के लिए समझने/अपनाने का तरीका आसान है आंतरिक अपवाद पर अपवाद फ़िल्टर का उपयोग करना याद रखें। हर कोई यह भी नहीं जानता कि अपवाद फ़िल्टर क्या है।

साथ ही, मैं पूरी तरह से मानता हूं कि यह उन परिदृश्यों में से एक है जहां कोई भी स्पष्ट जीत/कोई समझौता समाधान नहीं है, जैसा आपने कहा था।

हम उस बिंदु पर सहमत हुए @ericsampson लेकिन यह कई मौजूदा उपयोगकर्ताओं के लिए महत्वपूर्ण परिवर्तन होगा। जैसा कि @scalablecory ने उल्लेख किया है कि हमने संगतता क्षति को सीमित करते हुए सुधार करने के लिए समझौता किया है।

जब मैं अपवादों के बारे में सोचता हूं, सामान्य तौर पर, मैं रैपिंग दृष्टिकोण को बेहतर मानता हूं। ऑपरेशन रद्द अपवाद से अपवाद प्राप्त करना ऐसे अपवाद को केवल एसिंक्रोनस उपयोग में उपलब्ध कराता है। और यहां तक ​​कि यह कार्यों के लिए तंग है। जैसा कि हमने अतीत में देखा था कि एसिंक दृष्टिकोण के कई विकास थे और मैं कार्य को कार्यान्वयन विवरण के रूप में मानता हूं हालांकि टाइमआउट अपवाद, उदाहरण के लिए, सॉकेट अवधारणा का हिस्सा है जो नहीं बदलेगा।

हम उस बिंदु पर सहमत हुए @ericsampson लेकिन यह कई मौजूदा उपयोगकर्ताओं के लिए महत्वपूर्ण परिवर्तन होगा। जैसा कि @scalablecory ने उल्लेख किया है कि हमने संगतता क्षति को सीमित करते हुए सुधार करने के लिए समझौता किया है।

हालांकि मैं जरूरी नहीं कि रैपिंग विकल्प से असहमत हूं, मुझे लगता है कि यह इंगित करने लायक है - जहां तक ​​​​मैंने समझा है - मुद्दा यह नहीं है कि व्युत्पन्न विकल्प एक ब्रेकिंग बदलाव है, लेकिन रैपिंग एक आसान है। जैसा कि @stephentoub ने पहले चर्चा में उल्लेख किया था, एक व्युत्पन्न अपवाद को फेंकना कोरएफएक्स दिशानिर्देशों द्वारा एक ब्रेकिंग परिवर्तन नहीं माना जाता है।

टास्क रद्द किए गए अपवाद से HttpTimeoutException प्राप्त करना इन दो अपवादों के बीच "एक" संबंध का उल्लंघन करता है। यह अभी भी यह सोचने के लिए कॉलिंग कोड बनाएगा कि रद्दीकरण हुआ, जब तक कि यह विशेष रूप से HttpTimeoutException को संभालता नहीं है। यह मूल रूप से वही हैंडलिंग है जो हमें उस समय करनी होती है जब हम रद्दीकरण टोकन को रद्द करने की जांच करते हैं ताकि यह निर्धारित किया जा सके कि यह टाइमआउट है या नहीं। इसके अलावा, कोर लाइब्रेरी में दो टाइमआउट अपवाद होने से भ्रमित होता है।
TimeoutException को TaskCanceledException के आंतरिक अपवाद के रूप में जोड़ने से अधिकांश मामलों में कोई अतिरिक्त जानकारी नहीं मिलेगी, क्योंकि हम पहले से ही रद्दीकरण टोकन की जांच कर सकते हैं और यह निर्धारित कर सकते हैं कि यह टाइमआउट है या नहीं।

मुझे लगता है कि टाइमआउट अपवाद पर टाइमआउट पर फेंकने वाले अपवाद को बदलने का एकमात्र समझदार समाधान है। हां, यह एक ब्रेकिंग बदलाव होगा, लेकिन यह मुद्दा पहले से ही कई प्रमुख रिलीज तक फैला हुआ है और ब्रेकिंग बदलाव प्रमुख रिलीज के लिए हैं।

क्या मौजूदा संस्करणों के दस्तावेज़ीकरण को यह इंगित करने के लिए अद्यतन किया जा सकता है कि टाइमआउट होने पर विधियां TaskCanceledException और/या OperationCanceledException (दोनों ठोस प्रकार एक संभावना प्रतीत होती हैं) फेंक सकती हैं? वर्तमान में प्रलेखन इंगित करता है कि HttpRequestException टाइमआउट से संबंधित है, जो गलत और भ्रामक है।

@qidydl यह योजना है ... टाइमआउट प्रकट होने और उनके साथ विस्तार करने के किसी भी तरीके को पूरी तरह से दस्तावेज करेगा।

धन्यवाद @alnikola और @scalablecory और @davidsh और @karelz और इस चर्चा/कार्यान्वयन में शामिल सभी लोग, मैं वास्तव में इसकी सराहना करता हूं।