TypeError: getresponse() got an unexpected keyword argument 'buffering' #1915
Comments
|
For my own reference: this is 100% reproductible in changeset "2e3cbe6aed98" in my "heimdallr" Mercurial project, when running on master Raspberry PI. |
|
@jcea did you search other issues on the project? Your ticket reminded me of https://github.com/kennethreitz/requests/issues/1289 but I searched for To update you, there are patches on bugs.python.org which haven't moved anywhere because no core developers have bothered reviewing them. If you want action on this, your best bet is to go find those issues on bugs.python.org and bump them. I have done that myself but perhaps the more people who do so, the faster a response. Thanks for opening this, but it is a duplicate and it is not a bug in requests. |
|
The relevant section of the linked issue is this one (from this comment):
Please give that comment a read, it'll explain what you're actually seeing here. |
|
Hi, I get the same issue when my url has the local IP on which we are running the code on. If the IP is not the local IP and a remote IP, it all works fine. Error: Here is my code - __author__ = 'ramanr'
import cloudant
import requests
import math
import getInputs
database_name=''
test_id=''
db_uri=''
performance_view=''
inputs_dict = {}
def main():
global db_uri, database_name, test_id,performance_view
global avg_memory_threshold, avg_cpu_threshold, avg_fs_threshold
global inputs_dict
inputs_dict = getInputs.main()
database_name = inputs_dict['database_name']
test_id = inputs_dict['test_id']
db_uri = inputs_dict['db_uri']
performance_view = inputs_dict['performance_view']
updateScore()
def updateScore():
avg_memory_threshold = int(float(inputs_dict['avg_memory_threshold']))
avg_cpu_threshold = int(float(inputs_dict['avg_cpu_threshold']))
avg_fs_threshold = int(float(inputs_dict['avg_fs_threshold']))
# cpu_url = "http://10.247.32.72:5984/longevity/_design/perfstats/_view/cpu?StorageResourceManagement_3.0SP1_test1"
# memory_url = "http://10.247.32.72:5984/longevity/_design/perfstats/_view/memory?StorageResourceManagement_3.0SP1_test1"
# filesystem_url = "http://10.247.32.72:5984/longevity/_design/perfstats/_view/filesystem?StorageResourceManagement_3.0SP1_test1"
cpu_url = db_uri+'/'+database_name+'/'+'_design/'+performance_view+'/_view/'+'cpu?'+test_id
memory_url = db_uri+'/'+database_name+'/'+'_design/'+performance_view+'/_view/'+'memory?'+test_id
filesystem_url = db_uri+'/'+database_name+'/'+'_design/'+performance_view+'/_view/'+'filesystem?'+test_id
response = requests.get(cpu_url)
#print(response.json())
dict = response.json()
lists = dict['rows']
cpu_score = getScore(lists, avg_cpu_threshold)
response = requests.get(memory_url)
dict = response.json()
lists = dict['rows']
memory_score = getScore(lists,avg_memory_threshold )
response = requests.get(filesystem_url)
dict = response.json()
lists = dict['rows']
filesystem_score = getScore(lists,avg_fs_threshold)
score = round(math.ceil(((0.6*cpu_score)+(0.3*memory_score)+(0.1*filesystem_score))*100)/100, 1)
print(cpu_score,memory_score,filesystem_score,score)
updateDoc_score(db_uri, database_name, score)
def updateDoc_score(db_uri, database_name, score):
db_server = cloudant.Account(uri=db_uri)
db = db_server.database(database_name)
#test_id = test_id
doc = db.document(test_id)
doc.merge(({'score': score}))
def getScore(lists, threshold):
avg = math.ceil(lists[0]['value']*100)/100
#IF(G3<80,10,10-((G3-80)/2))
if avg < threshold:
score = 10
else:
score = 10 - (avg - threshold)/2
return(score)
#connect to couchDB and createDB (if necessory)
def updateDoc_errorCount():
db_server = cloudant.Account(uri=db_uri)
db = db_server.database(database_name)
#test_id = test_id
doc = db.document(test_id)
errorcount = 100
doc.merge(({'error_count': errorcount}))
if __name__ == "__main__":
main()So, I get the error on line 46(highlighted in the image below). If my url has the local IP, it doesnt work. If the url is has any other IP, it works. I am using python 3.3 and request 2.3.0
|
|
@rramanadham I edited your comment to make it easier to read (using fenced code blocks). The problem I'm having is that your traceback shows that the unhandled exception is a If you can get me the actual Traceback we can look at this again. If that traceback shows something different, I'd suggest we open a new issues but only if we determine this isn't someone killing the process. |
|
I am killing the process because if I dont kill it, it hangs forever. |
|
Right so this seems to be a different issue totally unrelated to this one you've commented on. What is |
|
db_uri = http://10.247.32.72:5984 |
|
What happens when you curl the URL you generate? |
|
nothing... i dont get response because the url is a couchdb view which runs based off documents that get created and my database has 0 documents. I don't know why. lglod078:~ # curl -X GET 'http://10.247.32.78:5984/longevity/_design/perfstats/_view/cpu?SRMSuite_3.0.2_test1' |
|
I'm confused: if you don't get a response when you use curl to get it, why would you expect one with requests? |
|
You are right. I didn't know that the curl commands weren't working. The other ones worked, so assumed, this works too. Sorry to take your time. I was struggling for 2 days on this and during the conversation, figured that the problem is somewhere else. Sorry! |
|
No need to apologise, I was just genuinely confused! You were quite right to have approached us, I just thought there was something I hadn't understood. =) |
|
Getting the same thing here. I am making a lot of queries to a JSON api, and this happens occasionally. Just did a batch of 100 with no issue. Before, it happened sometimes after around 20. Running on os-x 10.9, installed via |
|
@awbacker the real problem you're seeing has nothing to do with |
|
Okie. I figured I would get an error code of some kind and not an exception for that, and since it was in the middle I wasn't sure. Thanks for clearing that up, and forgive my newness at interpreting python stacktraces. Should I remove the comment and not muddy the issue? |
|
@awbacker when the connection is reset the only sane thing to do is throw an exception because the request/response cycle cannot be completed. Returning a
No worries. Python 3's stacktraces seem to be a source of frustration for a large number of people. This issue continues to see activity because of that exact reason.
No need to remove it. If others find this and read the entire comment history, maybe it will give them a hint as to how to find the real problem they're encountering. |
|
I'm getting a similar kind on error but with python3.4 library - File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py", line 319, in _make_request During handling of the above exception, another exception occurred: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): |
|
@piyushjajoo No you aren't. Please read this issue carefully. I made this comment, which linked to this comment from issue #1289. Once again, reproducing the body of the comment:
In your case, the real exception you care about is the last one: the |
|
Thanks, for pointing to correct issue. |
|
@Lukasa : wondering if the issue is related , however i am trying different option as you stated earlier , but none seems to work for me , Please suggest if you have any pointer: when I am making this api call to fetch the details from iCloud , it thows error
Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/requests/packages/urllib3/connectionpool.py:768: InsecureRequestWarning: Unverified HTTPS request is being made. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.org/en/latest/security.html During handling of the above exception, another exception occurred: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): The code which is making this call is host = self._service_root.split('//')[1].split(':')[0] Appreciate your support . I am currently using Python 3.4.3 .. |
|
This is not the same error, the error you're seeing is almost certainly #2568. |
|
Thanks for your response. |
|
As you can see on the discussion for #2568, we're working on it. in the meantime, you can resolve the problem by pinning to requests 2.6.0. |
|
I am new to python and requests, if I am doing anything wrong, please help me. Thanks! I am trying to write a crawler to automatically download some files using requests module. However, I met a problem. I initialized a new requests session, then I used post method to login into the website, after that as long as I try to use post/get method (a simplified code below): it will report error like the one below: I have totally no idea why this happens, can anyone help me? |
|
@1a1a11a Try upgrading to requests 2.7.0 (released yesterday), which should fix your problem. |
|
@Lukasa YES! After upgrading, the problems seems to be solved!!! Thank you a lot! |
|
@1a1a11a My pleasure. =) |
|
Thank heavens!! I just came here for this and it was fixed, also!!! |
|
Yay - fixed it for me |
|
I had the same problem. Fixed by updating requests |
|
Having the same problem with Python 3.5.0 and requests 2.9.1 on OS X 10.11 Traceback is almost the same as @1a1a11a |
|
@laike9m Please read the issue. As explained above, you are misreading the traceback. The actual exception you're hitting is the last one in the tree. That error is caused by the remote server closing the connection. |
|
@Lukasa Alright, understand. |
|
I still have this issue with request 2.13, python 3.5 as soon as the request timeout. Should the issue be reopened? |
|
@Cedric-Venet No you don't. You are seeing the effect of Python 3's exception chaining. Please read this issue very carefully. In fact, I'm now going to lock this issue because it is an absolute magnet for people chiming in with "me too" comments without reading the issue. For anyone who wants to leap in, here is the TL;DR. This is a problem to do with how exception tracebacks are being reported in Python 3. PEP 3134 introduced 'chaining exceptions' reporting, which means that when an exception bubbles up, all exceptions that were hit on the way to that original exception are shown. The purpose of this error reporting is to highlight that some exceptions occur in except blocks, and to work out what chain of exceptions was hit. This is potentially very useful: for instance, you can hit an exception after destroying a resource and then attempt to use that resource in the except block, which hits another exception. It's helpful to be able to see both exceptions at once. The key is that the |
Requests 2.2.1. Same thing happens in 1.2.3 (I upgraded from that).
I get this traceback:
The text was updated successfully, but these errors were encountered: