Requests: अधिकतम-पुन: प्रयास-पार किए गए अपवाद भ्रमित कर रहे हैं

को निर्मित 15 फ़र॰ 2013 · 39टिप्पणियाँ · स्रोत: psf/requests

नमस्ते,
उदाहरण के लिए:

>>> requests.get('http://localhost:1111')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "requests/api.py", line 55, in get
    return request('get', url, **kwargs)
  File "requests/api.py", line 44, in request
    return session.request(method=method, url=url, **kwargs)
  File "requests/sessions.py", line 312, in request
    resp = self.send(prep, **send_kwargs)
  File "requests/sessions.py", line 413, in send
    r = adapter.send(request, **kwargs)
  File "requests/adapters.py", line 223, in send
    raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 61] Connection refused)

(यह मानते हुए कि पोर्ट 1111 पर कुछ भी नहीं सुन रहा है)

अपवाद कहता है "अधिकतम पुनः प्रयास पार हो गए"। मुझे यह भ्रमित करने वाला लगा क्योंकि मैंने कोई पुनः प्रयास-संबंधित पैरा निर्दिष्ट नहीं किया था। वास्तव में, मैं पुनर्प्रयास-गणना निर्दिष्ट करने के बारे में कोई दस्तावेज नहीं ढूंढ पा रहा हूं। कोड के माध्यम से जाने के बाद, ऐसा लगता है कि urllib3 अंतर्निहित परिवहन है, और इसे max_retries = 0 के साथ कहा जाता है (इसलिए वास्तव में कोई पुनः प्रयास नहीं होता है)। और अनुरोध केवल अपवाद को लपेटता है। तो यह समझ में आता है, लेकिन यह एंड-यूज़र (एंड-डेवलपर) को भ्रमित करता है? मुझे लगता है कि यहां कुछ बेहतर किया जाना चाहिए, खासकर यह देखते हुए कि यह त्रुटि प्राप्त करना बहुत आसान है।

Feature Request

स्रोत

gabor

👍18

सबसे उपयोगी टिप्पणी

मैं मानता हूं कि यह काफी भ्रमित करने वाला है। अनुरोध कभी भी पुनः प्रयास नहीं करता है (यह urllib3 के HTTPConnectionPool के लिए पुनः प्रयास = 0 सेट करता है), इसलिए त्रुटि HTTPConnectionPool/MaxRetryError सामग्री के बिना अधिक स्पष्ट होगी। मुझे अभी तक urllib3 उपयोग किए गए अनुरोधों का एहसास नहीं हुआ, जब मुझे दोनों पुस्तकालयों के स्रोत कोड में गोता लगाना पड़ा ताकि मुझे यह पता चल सके कि यह कितने पुन: प्रयास कर रहा था:

ConnectionError(MaxRetryError("HTTPSConnectionPool(host='api.venere.com', port=443): \
    Max retries exceeded with url: /xhi-1.0/services/XHI_HotelAvail.json (\
    Caused by <class 'socket.error'>: [Errno 10054] \
    An existing connection was forcibly closed by the remote host)",),)

आदर्श रूप से अपवाद कुछ इस तरह दिखेगा:

ConnectionError(<class 'socket.error'>: [Errno 10054] \
    An existing connection was forcibly closed by the remote host))

benhoyt 9 अप्रैल 2013

👍4

सभी 39 टिप्पणियाँ

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

sigmavirus24 15 फ़र॰ 2013

मुझे लगता है कि कुछ त्रुटि को अनदेखा करने के लिए एक ऑटो पुनः प्रयास की आवश्यकता है

zew13 21 फ़र॰ 2013

ConnectionError(MaxRetryError("HTTPSConnectionPool(host='api.venere.com', port=443): \
    Max retries exceeded with url: /xhi-1.0/services/XHI_HotelAvail.json (\
    Caused by <class 'socket.error'>: [Errno 10054] \
    An existing connection was forcibly closed by the remote host)",),)

आदर्श रूप से अपवाद कुछ इस तरह दिखेगा:

ConnectionError(<class 'socket.error'>: [Errno 10054] \
    An existing connection was forcibly closed by the remote host))

benhoyt 9 अप्रैल 2013

👍4

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

sigmavirus24 9 अप्रैल 2013

हमें उस मामले पर भी विचार करना होगा जहां उपयोगकर्ता _does_ पुन: प्रयास कॉन्फ़िगर करता है, इस मामले में यह अपवाद उपयुक्त है।

Lukasa 9 अप्रैल 2013

@ लुकासा , मुझे यकीन नहीं है कि आपको इस पर विचार करने की आवश्यकता है - केनेथ ने यहां कहा कि अनुरोधों को स्पष्ट रूप से इसके एपीआई के हिस्से के रूप में पुनर्प्रयास का समर्थन नहीं करना चाहिए।

benhoyt 9 अप्रैल 2013

ठीक है, लेकिन उपयोगकर्ता को वास्तव में ऐसा करने से रोकने का कोई तरीका नहीं है।

मेरी योजना, रिकॉर्ड के लिए, जितना संभव हो उतना नीचे की ओर सबसे निचले स्तर के अपवाद को पार करना है और इसके बजाय इसका उपयोग करना है। @benhoyt के उदाहरण के साथ समस्या यह है कि ऐसा लगता है कि सॉकेट त्रुटि अपवाद हमारे लिए अनुपलब्ध है। (बस यह देखकर कि उसने क्या चिपकाया है। मैंने अभी तक इसे पुन: पेश करने और इसके साथ खेलने की कोशिश नहीं की है।)

sigmavirus24 9 अप्रैल 2013

@gabor का उदाहरण वास्तव में इसे पुन: पेश करना आसान बनाता है। उठाए गए अपवाद को पकड़कर, मैंने निम्न कार्य किया:

>>> e
ConnectionError(MaxRetryError("HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 111] Connection refused)",),)
>>> e.args
(MaxRetryError("HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 111] Connection refused)",),)
>>> e.args[0].args
("HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 111] Connection refused)",)
>>> e.args[0].args[0]
"HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 111] Connection refused)"
>>> isinstance(e.args[0].args[0], str)
True

तो सबसे अच्छा हम केवल e.args[0].args[0] में संग्रहीत संदेश का उपयोग कर सकते हैं जो संभावित रूप से भ्रमित भी हो सकता है, लेकिन शायद @benhoyt का सामना करने से कम है। किसी भी तरह से, हम अधिक या कम विवरण प्राप्त करने का प्रयास करने के लिए त्रुटि संदेशों का विश्लेषण नहीं करेंगे क्योंकि यह केवल पूर्ण पागलपन होगा।

sigmavirus24 9 अप्रैल 2013

@ सिग्मावायरस 24 , मैं मानता हूं कि अपवादों में स्ट्रिंग पार्सिंग एक भयानक विचार है। हालांकि, urllib3 का MaxRetryError पहले से ही एक reason विशेषता को उजागर करता है जिसमें अंतर्निहित अपवाद होता है ( स्रोत कोड देखें)। तो आप e.args[0].reason साथ जो चाहें प्राप्त कर सकते हैं।

इसलिए उपरोक्त उदाहरण के अनुसार, e.args[0].reason का एक उदाहरण है socket.error :

>>> requests.get('http://localhost:1111')
Traceback (most recent call last):
  ...
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 10061] No connection could be made because the target machine actively refused it)
>>> e = sys.last_value
>>> e
ConnectionError(MaxRetryError("HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 10061] No connection could be made because the target machine actively refused it)",),)
>>> e.args[0]
MaxRetryError("HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 10061] No connection could be made because the target machine actively refused it)",)
>>> e.args[0].reason
error(10061, 'No connection could be made because the target machine actively refused it')

benhoyt 10 अप्रैल 2013

अच्छा कैच @benhoyt। मैं urllib3 से उतना परिचित नहीं हूँ जितना मैं बनना चाहता हूँ।

sigmavirus24 10 अप्रैल 2013

यदि यह वास्तव में वैसा ही दिखता है जैसा आपने दिखाया था।
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=1111): Max retries exceeded with url: / (Caused by <class 'socket.error'>: [Errno 61] Connection refused)

तब मैं वास्तव में बेहतर अपवाद का सपना नहीं देख सकता था।

piotr-dobrogost 10 अप्रैल 2013

@ piotr-dobrogost, मुख्य समस्या (मेरे लिए) यह तथ्य था कि यह "अधिकतम पुनर्प्रयास पार हो गया" के बारे में बात करता है, जब इसमें कोई पुनः प्रयास शामिल नहीं होता है। पहले तो मुझे लगा कि यह वह वेब सेवा है जिसका मैं यह कहकर उपयोग कर रहा था, इसलिए मैंने उनसे संपर्क किया। फिर, आगे खुदाई करने पर, मुझे पता चला कि यह एक urllib3 quirk था। तो आप भ्रम देख सकते हैं।

benhoyt 10 अप्रैल 2013

क्या आप अपवाद के (Caused by <class 'socket.error'>: [Errno 61] Connection refused) भाग से चूक गए हैं?

piotr-dobrogost 10 अप्रैल 2013

हाँ, तुम सही हो - यह सब वहाँ है। लेकिन जैसा कि मैंने उल्लेख किया है, मैंने इसे पहले याद किया, क्योंकि MaxRetryError एक लाल हेरिंग है।

benhoyt 10 अप्रैल 2013

यह मैक्सिमम रिट्रीज चीज मुझे हमेशा पागल कर देती है। क्या किसी को कोई आपत्ति है अगर मैं इसमें गोता लगाऊं और देखूं कि क्या मैं पुनः प्रयास संदेश को स्क्वैश करने के लिए पीआर को एक साथ नहीं रख सकता हूं?

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

ksnavely 8 फ़र॰ 2014

उत्तर है _शायद_।

समस्या यह है कि, जबकि डिफ़ॉल्ट रूप से हम कोई पुन: प्रयास नहीं करते हैं, आप विफल अनुरोधों को स्वचालित रूप से पुनः प्रयास करने के लिए अनुरोधों को कॉन्फ़िगर कर सकते हैं। उन स्थितियों में, हमने जो MaxRetryError लपेटा है वह पूरी तरह से उचित है। यदि आप कोई ऐसा समाधान लेकर आ सकते हैं जो MaxRetryError को यथास्थिति में छोड़ देता है, लेकिन इसे हटा देता है जब आप गारंटी दे सकते हैं कि कोई पुन: प्रयास प्रयास नहीं किया गया है, तो हम इस पर विचार करेंगे। =)

Lukasa 8 फ़र॰ 2014

@ लुकासा धन्यवाद, मैं यहां बैकलॉग पर खुद को रीफ्रेश कर रहा हूं। अगर मुझे गोता लगाने का मौका मिला तो मैं जरूर पहुंचूंगा।

ksnavely 8 फ़र॰ 2014

यह लगभग मुझे ऐसा लगता है जैसे परिवर्तन के लिए सही जगह urllib3 में है? MaxRetryError स्वचालित पुनर्प्रयासों के संदर्भ में बढ़ाने के लिए समझ में आता है, लेकिन शून्य पुनर्प्रयास (शायद अनुभवहीन अनुरोध अनुभव) के मामले में यह भ्रमित हो सकता है।

urllib3 में ऐसा लगता है कि भ्रमित त्रुटियों को अनुरोधों के माध्यम से यहां ट्रिगर किया जा सकता है। जब retries==0 and max_retries!=0 हो तो केवल MaxRetryError उठाना लगभग अच्छा होगा। यदि max_retries==0 बजाय एक सादा RequestError उठाया गया था।

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

ksnavely 9 फ़र॰ 2014

urllib3 में फिक्स है या नहीं, यह पूरी तरह से @shazow पर निर्भर करता है। यह देखते हुए कि urllib3 डिफ़ॉल्ट रूप से _does_ पुनः प्रयास करें (3 बार IIRC), हो सकता है कि वह urllib3 के व्यवहार को वैसा ही रखना चाहता हो। अपना इनपुट प्राप्त करने के लिए उसे पिंग करना।

हम कुछ निर्भरता मुद्दों से बचने के लिए urllib3 विक्रेता हैं। अनिवार्य रूप से, इसका अर्थ है कि हम हमेशा urllib3 के ज्ञात संस्करण के विरुद्ध कार्य कर रहे हैं। यदि आप किरकिरा विवरण चाहते हैं तो # 1384 और # 1812 में कष्टदायी लंबाई पर इस पर चर्चा की गई है।

Lukasa 9 फ़र॰ 2014

ओह किरकिरा लेकिन जानकारीपूर्ण। @shazow ये मेरे कुछ ही विचार हैं - ऊपर दिए गए MaxRetryError के बजाय एक RequestError उठाना। वास्तव में मुझे लगता है कि मैं बेहतर बाहर की जाँच के बाद MaxRetryError को समझने urlopen ।

दोहरा संपादन: वास्तव में केवल एक क्वार्ग ताकि कोई raise MaxRetryError(retries=0) और संदेश को retries==0 पर बदल सके।

ksnavely 9 फ़र॰ 2014

कैसे एक retries=False जो पूरी तरह से पुनर्प्रयास अक्षम कर देगा और हमेशा MaxRetryError बजाय मूल अपवाद बढ़ाएगा?

shazow 9 फ़र॰ 2014

urlopen को बिना किसी पुनर्प्रयास के पूछने और पुनर्प्रयासों की संख्या पर 0 तक गिनने के बीच अंतर करने में सक्षम होना उपयोगी होगा। जब आपने पुन: प्रयास करने के लिए नहीं कहा तो MaxRetryError देखकर झकझोर रहा है।

cash 19 फ़र॰ 2014

अगर कोई इसके लिए पैच + टेस्ट करना चाहेगा, तो इसकी सराहना की जाएगी। :)

shazow 19 फ़र॰ 2014

@shazow बढ़िया, अगर मैं साइकिल ढूंढ सकता हूं तो मैं खेल

ksnavely 19 फ़र॰ 2014

\ओ/

shazow 19 फ़र॰ 2014

^मैं सोच रहा था कि क्या कोई पैच जारी किया गया था? मामला एक साल पुराना लगता है।

arcolife 26 अग॰ 2014

जहाँ तक मेरी जानकारी है, नहीं। =)

Lukasa 26 अग॰ 2014

retries=False को मूल अपवाद को v1.9 के रूप में उठाना चाहिए, कोई रैपिंग नहीं।

shazow 2 सित॰ 2014

@kevinburke विचार?

sigmavirus24 5 अक्तू॰ 2014

थोड़ा और समय चाहिए

केविन बर्क
फोन: 925.271.7005 | ट्वेंटीमिलीसेकंड्स.कॉम
5 अक्टूबर 2014 को सुबह 10:37 बजे, इयान कॉर्डास्को नोटिफिकेशन @github.com
लिखा था:
@kevinburke https://github.com/kevinburke विचार?
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/kennethreitz/requests/issues/1198#issuecomment -57945403
.

kevinburke 5 अक्तू॰ 2014

हाँ यह तय हो गया है मुझे लगता है

requests.get('http://localhost:11211')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "requests/api.py", line 60, in get
    return request('get', url, **kwargs)
  File "requests/api.py", line 49, in request
    return session.request(method=method, url=url, **kwargs)
  File "requests/sessions.py", line 457, in request
    resp = self.send(prep, **send_kwargs)
  File "requests/sessions.py", line 569, in send
    r = adapter.send(request, **kwargs)
  File "requests/adapters.py", line 407, in send
    raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: ('Connection aborted.', error(61, 'Connection refused'))

kevinburke 5 अक्तू॰ 2014

क्या आप कृपया मुझे बता सकते हैं कि इसे कैसे हल किया गया है, क्योंकि मुझे भी मेरी ओर से कनेक्शन अस्वीकृत समस्या मिल रही है। मेरी पायथन लिपि में मैं आरपीसी सर्वर को जोड़ने की कोशिश कर रहा हूं

SiddheshS 22 फ़र॰ 2016

@ सिद्धेश इस मुद्दे को कुछ अपवादों को फिर से स्टैक ओवरफ़्लो का उपयोग करने पर विचार करना चाहिए।

Lukasa 22 फ़र॰ 2016

मुझे एक ही समस्या का सामना करना पड़ा। यह कभी-कभार हुआ। कैसे ठीक करें, क्या कोई मेरी मदद कर सकता है? ।धन्यवाद।

request.exceptions.ConnectionError: HTTPSConnectionPool(host='api.xxxx.com', port=443): अधिकतम पुनर्प्रयास url के साथ पार हो गए: /v2/goods/?category=0&sort_type=2&page_size=3&page_num=13&t=0&count=110 (कारण) NewConnectionError द्वारा (': एक नया कनेक्शन स्थापित करने में विफल: [Errno 110] कनेक्शन का समय समाप्त हो गया',))
ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "test.py", लाइन ३३५, in
मुख्य()
फ़ाइल "test.py", लाइन २९०, मुख्य में
परिणाम = get_goods_info ()
फ़ाइल "test.py", लाइन 67, get_goods_info . में
परिणाम = अनुरोध। प्राप्त करें (यूआरएल)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/api.py", लाइन 69, प्राप्त करने में
वापसी अनुरोध ('प्राप्त करें', url, params = params, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/api.py", लाइन 50, अनुरोध में
प्रतिक्रिया = session.request (विधि = विधि, url = url, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/sessions.py", लाइन 468, अनुरोध में
सम्मान = स्वयं भेजें (प्रस्तुत करने का, *_send_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/sessions.py", लाइन 576, भेजने में
आर = एडेप्टर। भेजें (अनुरोध, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/adapters.py", लाइन 423, भेजने में
कनेक्शन बढ़ाएं त्रुटि (ई, अनुरोध = अनुरोध)

nkjulia 3 मई 2016

@nkjulia कनेक्शन का प्रयास समय समाप्त हो रहा है, जो बताता है कि दूरस्थ सर्वर अतिभारित है या आपका कनेक्शन टाइमआउट बहुत कम है।

Lukasa 3 मई 2016

मैं भी इससे गुमराह हुआ....

linzhi 20 जुल॰ 2017

@kevinburke कनेक्शन अस्वीकृत त्रुटि मिलने के बाद आपकी समस्या का समाधान कैसे हुआ? क्या आप कृपया दोस्त को सलाह दे सकते हैं। तिया

duginivijay 18 सित॰ 2017

मेरे पोस्ट मेट पर ध्यान न दें। मेरी मशीन में अजगर के कई संस्करण थे, जिसके कारण वह सही को नहीं चुन पा रहा था और त्रुटि फेंक रहा था। इस सोच को पोस्ट करना किसी के लिए मददगार हो सकता है।

duginivijay 18 सित॰ 2017

मुझे एक ही समस्या का सामना करना पड़ा। यह कभी-कभार हुआ। कैसे ठीक करें, क्या कोई मेरी मदद कर सकता है? ।धन्यवाद।
request.exceptions.ConnectionError: HTTPSConnectionPool(host='api.xxxx.com', port=443): अधिकतम पुनर्प्रयास url के साथ पार हो गए: /v2/goods/?category=0&sort_type=2&page_size=3&page_num=13&t=0&count=110 (कारण) NewConnectionError द्वारा (': एक नया कनेक्शन स्थापित करने में विफल: [Errno 110] कनेक्शन का समय समाप्त हो गया',))
ट्रेसबैक (सबसे हालिया कॉल अंतिम):
फ़ाइल "test.py", लाइन ३३५, in
मुख्य()
फ़ाइल "test.py", लाइन २९०, मुख्य में
परिणाम = get_goods_info ()
फ़ाइल "test.py", लाइन 67, get_goods_info . में
परिणाम = अनुरोध। प्राप्त करें (यूआरएल)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/api.py", लाइन 69, प्राप्त करने में
वापसी अनुरोध ('प्राप्त करें', url, params = params, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/api.py", लाइन 50, अनुरोध में
प्रतिक्रिया = session.request (विधि = विधि, url = url, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/sessions.py", लाइन 468, अनुरोध में
सम्मान = स्वयं भेजें (प्रस्तुत करने का, *_send_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/sessions.py", लाइन 576, भेजने में
आर = एडेप्टर। भेजें (अनुरोध, *_kwargs)
फ़ाइल "/usr/local/lib/python2.7/site-packages/requests/adapters.py", लाइन 423, भेजने में
कनेक्शन बढ़ाएं त्रुटि (ई, अनुरोध = अनुरोध)

अगर यह समस्या हल हो गई है, तो कृपया मुझे कुछ सलाह दें।

pigga 27 दिस॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Requests: अधिकतम-पुन: प्रयास-पार किए गए अपवाद भ्रमित कर रहे हैं

सबसे उपयोगी टिप्पणी

सभी 39 टिप्पणियाँ

संबंधित मुद्दों