[issue24755] asyncio.wrap_future undocumented
Changes by Andrej A Antonov <polymor...@gmail.com>: -- nosy: +polymorphm ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
for testing broken-connection? answer:',
s.getsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE)
)
# answer is 0 (false) -- for all GNU/Linux
my previous code-example has 100-iteration -- only for we could catch the
right-moment when testing (and for nothing else).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14134
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. system-timeout works on GNU/Linux -- only if was custom-set tcpkeepalive, else (by default): even after 5 days system-timeout was not reached. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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)
#!/usr/bin/env python3
import threading
from xmlrpc.client import ServerProxy
ITERATION_COUNT = 100
THREAD_COUNT = 100
def thread_func(thread_name):
for i in range(ITERATION_COUNT):
try:
server = ServerProxy(http://betty.userland.com;)
rpc_result = server.examples.getStateName(41)
print('{}/iter_{} {!r}'.format(thread_name, i, rpc_result))
except Exception as e:
print('{}/iter_{} error: {} {}'.format(thread_name, i, type(e),
str(e)))
def main():
print('* testing begin *')
thread_list = []
for i in range(THREAD_COUNT):
thread_name = 'thread_{}'.format(i)
thread_list.append(threading.Thread(target=thread_func,
args=(thread_name,)))
for thr in thread_list:
thr.start()
for thr in thread_list:
thr.join()
print('* testing end *')
if __name__ == '__main__':
main()
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14134
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov added the comment: good patch (issue14134.patch) ! thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 practice for other things.
and again -- compare what shorter (and what more clear):
proxy = ServerProxy('http://example.com/gateway/', transport=Transport(
connection_factory=lambda h: HTTPConnection(h, timeout=42)))
or
proxy = ServerProxy('http://example.com/gateway/', timeout=42)
There should be one-- and preferably only one --obvious way to do it..
Having a timeout at the top level ServerProxy object introduces ambiguity and
therefore doesn't conform
if you NOT point timeout in RPC-client -- you program will freeze or will
maked resource leak (with small probability).
RPC-client and timeout -- these two concepts are inseparable!
you are allowed *NOT_using* timeout in RPC-client -- *ONLY* in *localhost*
operations!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14134
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. default value of timeout for default transport -- what may be this number? may be value 300 for timeout of default transport (xmlrpc.client.Transport()) may be normal in *most_cases*. but this will brake legacy soft that using socket.setdefaulttimeout(...) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 a leak. If you have an example of such a case, it would likely be a good candidate for a new issue. I do not know how behavior in Microsoft Windows... in GNU/Linux system timeout has been reached -- means that system timeout will *never* reached. you may easy to test this (to make this test -- we need using: client-computer and network-router-computer): step 1. run next code on client-computer (GNU/Linux): $ python3 from xmlrpc.client import ServerProxy server = ServerProxy(http://betty.userland.com;) for _ in range(100): print(server.examples.getStateName(41)) step 2: to broke network in network-router-computer. step 3: wait some minutes. example 60 minutes. step 4: to repear netework in network-router-computer. step 5: we will see, that program on client-computer will freeze *forever*. system timeout will *never* reached. even after some days -- system timeout will not reached. :-) it would likely be a good candidate for a new issue. yes, may be we need new issue-ticket? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- it is mistake). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21356] Support LibreSSL (instead of OpenSSL): make RAND_egd optional
Changes by Andrej A Antonov polymor...@gmail.com: -- nosy: +polymorphm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21356 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy needs timeout parameter
Andrej A Antonov polymor...@gmail.com 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 theoretical-side -- this layer isolation may be good and clean. but in practical-side -- situation is next: there are 3 alternative-variants of using timeout parameter in XMLRPC-Client: situation 1. programmer (who makes script or program) -- using XMLRPC-Client *WITH* timeout parameter, because timeout parameter should be using in his program. program runs in regular environment. situation 2. programmer (who makes script or program) -- using XMLRPC-Client *WITHOUT* timeout parameter, because XMLRPC-connection runs in localhost environment. situation 3. programmer (who makes script or program) -- using XMLRPC-Client *WITHOUT* timeout parameter, because he makes mistake. situation 1 -- very often. (or must be very often). situation 2 -- very rare. situation 3 -- leads to possible cases of freezing program/script or resource-leak. if we will try to hide timeout parameter (in other layer), then situation 3 will be more than situation 1 # p.s.: sorry for my bad english -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy() -- need for timeout-parameter
Andrej A Antonov polymor...@gmail.com added the comment: in this subject -- I think about like this changes (see file example-of-changes.patch) -- keywords: +patch Added file: http://bugs.python.org/file24675/example-of-changes.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14134] xmlrpc.client.ServerProxy() -- need for timeout-parameter
New submission from Andrej A Antonov polymor...@gmail.com: good day! xmlrpc.client.ServerProxy() -- not has timeout-parameter xmlrpc.client.Transport() and xmlrpc.client.SafeTransport() -- not has timeout-parameter too but http.client.HTTPConnection() and http.client.HTTPSConnection() -- has timeout-parameter -- components: Library (Lib) messages: 154409 nosy: polymorphm priority: normal severity: normal status: open title: xmlrpc.client.ServerProxy() -- need for timeout-parameter type: enhancement versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14134 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
