[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Change by Matt Prahl : -- nosy: +mprahl nosy_count: 7.0 -> 8.0 pull_requests: +21025 pull_request: https://github.com/python/cpython/pull/21909 ___ Python tracker ___ _

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Change by Roundup Robot : -- nosy: +python-dev nosy_count: 6.0 -> 7.0 pull_requests: +21024 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/21908 ___ Python tracker ___

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: I withdraw my patch as (I just discovered), it is already possible to effect changes to the underlying connection. What /should/ be done is: transport = Transport() con = transport.make_connection([host]) con.timeout = 2 proxy = ServerProxy([url], transport=tra

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Changes by Demian Brecht : Removed file: http://bugs.python.org/file37481/issue14134.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: good patch (issue14134.patch) ! thanks! -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: I've attached a test-less patch with my suggested approach. If there's no opposition to this change, I'll put some work into getting tests done for it as well. -- Added file: http://bugs.python.org/file37481/issue14134.patch ___

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: On another note, running a simple test with against a non-routable IP yields that OSX's default timeout is 75 seconds and not 7500 seconds as the developer docs lead me to believe. -- ___ Python tracker

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: I think we've started to venture into system-level territory that the standard library itself shouldn't have to account for. If TCP on systems are configured by default to allow for infinite timeouts, then it should likely be an issue for those distros. I don't

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: @demian.brecht , for high probably to catch *infinite_freeze* (at GNU/Linux) -- if we may will run requests of "xmlrpc.client.ServerProxy" -- parallely: (when running next code -- need to make some network-disconnections on "network-router-computer")

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: >> in GNU/Linux "system timeout has been reached" -- means that system timeout >> will *never* reached. > That's quite likely because the system limits may be very large. I tested system-timeout GNU/Linux (on various computers). I waited more then 5 days.

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: I just will write next code-fragment: import socket s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_TCP) s.connect(('python.org', 80)) print( 'is my operation system using (by default) "tcpkeepalive"-algorithm

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: > in GNU/Linux "system timeout has been reached" -- means that system timeout > will *never* reached. That's quite likely because the system limits may be very large. For example, on my OSX box: --- ~ » sysctl net.inet.tcp.keepinit net.inet.tcp.keepin

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: >> if you NOT point timeout in "RPC-client" -- you program will freeze or will >> maked resource leak (with small probability). > Assuming a lack of concurrency, your program will indeed freeze until the > system timeout has been reached. I'm not sure about

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: > socket.setdefaulttimeout([timeout]) -- it is bad practice I'm not really arguing this. It solves the problem, but definitely not in the best of ways. My point in referencing setdefaulttimeout is that if /all/ you care about is the timeout and you're horribly

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: ok, let's go to other side of this problem: question: why default transport (xmlrpc.client.Transport()) is not setting value of timeout?`` answer: because *unknown* which value need to using by default. in various cases programmer need various timeout. defa

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: @demian.brecht , socket.setdefaulttimeout([timeout]) -- it is bad practice, because setting this global varible we may spoil other cases. example "TCP keepalive" [ s.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, true) ] and global variables is bad pract

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: + loewis as he's listed as the xmlrpc expert If you're worried about the number of lines, turn the function into a lambda: proxy = ServerProxy('http://example.com/gateway/', transport=Transport( connection_factory=lambda h: HTTPConnection(h, timeout=

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: @demian.brecht , your example code-fragment is too big. :-) too many lines -- just only for adding "timeout". it is uncomfortably. most people will not using that: most likely they just will forget about "timeout" (but in *MOST* situations not using "timeout

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Demian Brecht added the comment: I'm a -1 to adding the timeout parameter to the ServerProxy implementation for pretty much the same reasons Jeff mentioned, but mainly because of the ambiguity that is introduced between the timeout and transport parameters (who should win in the case that they

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Changes by Berker Peksag : -- nosy: +berker.peksag ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Changes by Florent Xicluna : -- nosy: +flox versions: +Python 3.5 -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Jeff McNeil added the comment: Yeah, that's a good point too. I still personally favor the transport encapsulation and related unit testing, but I think that's a call for someone with a snake icon next to their tracker name. Your English is just fine. =) -- _

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Andrej A Antonov added the comment: Jeff McNeil (mcjeff)> I would think it might make more sense just to make the change to the Transport object. Since there's an argument for a transport on ServerProxy already, that seems more straightforward and keeps the network layer isolated. in theoret

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Jeff McNeil added the comment: I would think it might make more sense just to make the change to the Transport object. Since there's an argument for a transport on ServerProxy already, that seems more straightforward and keeps the network layer isolated. Otherwise, it seems slightly ambiguou

[issue14134] xmlrpc.client.ServerProxy needs timeout parameter

Changes by Éric Araujo : -- stage: -> test needed title: "xmlrpc.client.ServerProxy()" -- need for "timeout"-parameter -> xmlrpc.client.ServerProxy needs timeout parameter ___ Python tracker