Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(XMLRPC) multitude of sockets ending up in TIME_WAIT #41621

Closed
jonsv322 mannequin opened this issue Feb 25, 2005 · 4 comments
Closed

(XMLRPC) multitude of sockets ending up in TIME_WAIT #41621

jonsv322 mannequin opened this issue Feb 25, 2005 · 4 comments

Comments

@jonsv322
Copy link
Mannequin

jonsv322 mannequin commented Feb 25, 2005

BPO 1151968
Nosy @loewis, @birkenfeld

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-03-17.19:29:02.000>
created_at = <Date 2005-02-25.18:00:50.000>
labels = ['OS-windows']
title = '(XMLRPC) multitude of sockets ending up in TIME_WAIT'
updated_at = <Date 2006-03-17.19:29:02.000>
user = 'https://bugs.python.org/jonsv322'

bugs.python.org fields:

activity = <Date 2006-03-17.19:29:02.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2005-02-25.18:00:50.000>
creator = 'jonsv322'
dependencies = []
files = []
hgrepos = []
issue_num = 1151968
keywords = []
message_count = 4.0
messages = ['24365', '24366', '24367', '24368']
nosy_count = 3.0
nosy_names = ['loewis', 'georg.brandl', 'jonsv322']
pr_nums = []
priority = 'normal'
resolution = 'works for me'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1151968'
versions = []

@jonsv322
Copy link
Mannequin Author

jonsv322 mannequin commented Feb 25, 2005

A problem with a multitude of sockets ending up in
TIME_WAIT when stressing a system with XML-RPC calls.
This can cause a Windows network to missbehave.

A solution on Windows platform is to set the sockopt
NOLINGER with parameters (1, 0) for the socket before
the socket is closed. This vill cause that Windows will
release the socket direct without going into TIME_WAIT.

The solution in code:
In httplib.py@somewhere:
NOLINGER = struct.pack('HH', 1, 0) # Release the
resource back to the system if socket closed

In httplib.py@632:
self.sock.setsockopt(socket.SOL_SOCKET,
socket.SO_LINGER, NOLINGER)
self.sock.close() # close it manually... there may be
other refs

@jonsv322 jonsv322 mannequin closed this as completed Feb 25, 2005
@jonsv322 jonsv322 mannequin added the OS-windows label Feb 25, 2005
@jonsv322 jonsv322 mannequin closed this as completed Feb 25, 2005
@jonsv322 jonsv322 mannequin added the OS-windows label Feb 25, 2005
@jonsv322
Copy link
Mannequin Author

jonsv322 mannequin commented Feb 25, 2005

Logged In: YES
user_id=352221

Read section, SO_LINGER at following address:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wspsetsockopt_2.asp

@loewis
Copy link
Mannequin

loewis mannequin commented Feb 25, 2005

Logged In: YES
user_id=21627

Why do you want to avoid the TIME_WAIT state, and why do you
think it is a Python bug that it doesn't? See

http://www.developerweb.net/sock-faq/detail.php?id=13

where Richard Stevens himself explains that SO_LINGER should
*not* be used.

It might be that SO_REUSEADDR is sufficient, see

http://www.developerweb.net/sock-faq/detail.php?id=44

If you want xmlrpclib to use different socket options, you
should subclass httplib.HTTP to redefine either connect() or
close(), and you should subclass xmlrpclib.Transport to use
your subclassed transport.

@birkenfeld
Copy link
Member

Logged In: YES
user_id=849994

Seems like Not a Bug.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant