471,319 Members | 1,574 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,319 software developers and data experts.

How to stop an [Rpyc] server thread?

I embedded an Rpyc threaded server in a preexistent daemon (an irc
bot), this is actually very simple;
start_threaded_server(port = DEFAULT_PORT)
then I had the necessity to stop the thread which accept() new
connections without killing the whole app, the thread is simply a while
True that spawn a new thread which serves each connection, so I placed
a flag and a break in this way:
def local_threaded_server(port = DEFAULT_PORT, **kw):
global stop
sock = create_listener_socket(port)
while True:
newsock, name = sock.accept()
t = Thread(target = serve_socket, args = (newsock,),
kwargs = kw)
t.setDaemon(True)
t.start()
if stop: break
but, since sock.accept() blocks, when I set stop=True the server wait
one more connection and only then stops.
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
44, in read
buf = self.sock.recv(count)
socket.error: (10053, 'Software caused connection abort')

OR
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
82, in __repr__
return self.__request__("handle_repr", *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\NetProxy.py", line
113, in __request__
return _get_conn(self).sync_request(handler, _get_oid(self), *args)
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 143, in sync_request
self.serve()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Connection.py",
line 126, in serve
type, seq, data = self.channel.recv()
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Channel.py", line
50, in recv
type, seq, length = struct.unpack(self.HEADER_FORMAT,
self.stream.read(self.HEADER_SIZE))
File "C:\Programmi\Python24\lib\site-packages\Rpyc\Stream.py", line
46, in read
raise EOFError()
EOFError

I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.

Sep 7 '06 #1
3 5447

Saizan wrote:
I embedded an Rpyc threaded server in a preexistent daemon (an irc
bot), this is actually very simple;
start_threaded_server(port = DEFAULT_PORT)
then I had the necessity to stop the thread which accept() new
connections without killing the whole app, the thread is simply a while
True that spawn a new thread which serves each connection, so I placed
a flag and a break in this way:
def local_threaded_server(port = DEFAULT_PORT, **kw):
global stop
sock = create_listener_socket(port)
while True:
newsock, name = sock.accept()
t = Thread(target = serve_socket, args = (newsock,),
kwargs = kw)
t.setDaemon(True)
t.start()
if stop: break
First off, instead of the "while True" and the break, you could write:
while not stop:
but, since sock.accept() blocks, when I set stop=True the server wait
one more connection and only then stops.
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
[snip]
I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.
Now to the real issue. I've also had such weird problems with socket
timeout in Python. The best workaround I found is to use select() to
check for activity on the socket(s), and use select()'s timeout
mechanism. So far, this has worked without a hitch on both WindowsXP
and Solaris Sparc9 installations.

- Tal
reduce(lambda m,x:[m[i]+s[-1] for i,s in enumerate(sorted(m))],
[[chr(154-ord(c)) for c in '.&-&,l.Z95193+179-']]*18)[3]

Sep 8 '06 #2
Saizan wrote:
[...]
I tried sock.settimeout(10) before entering the while and so checking
timeout exception on accept() but I experienced a strange behavior, the
clients connections close immediatly, with one of these exceptions on
the client side on their first use of the rpc connection:
[...]
socket.error: (10053, 'Software caused connection abort')
[...]
EOFError

I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
After modest investigation, it looks like a bug in Python's
sockets, at least on WinXP.

Try inserting the line after accept():

[...]
newsock, name = sock.accept()
newsock.settimeout(None)
[...]
--
--Bryan
Sep 12 '06 #3
7 Sep 2006 23:38:08 -0700, Tal Einat <ta************@gmail.com>:
I'm not an expert in socket programming, but I can't see the
correlation between the "listener socket" being in timeout mode and a
different behavior the other sockets..
Anyhow the main goal is being able to shut down the thread of the rpyc
server, any other way is an appreciated suggestion.

Now to the real issue. I've also had such weird problems with socket
timeout in Python. The best workaround I found is to use select() to
check for activity on the socket(s), and use select()'s timeout
mechanism. So far, this has worked without a hitch on both WindowsXP
and Solaris Sparc9 installations.
Twisted[1] is the answer. I've never seen a better framework for using
sockets, it's painless. I created two versions of the same protocol
(both client and server), one using sockets + select, another using
Twisted. The sockets version had 2x lines than the Twisted one and
lots of bugs. Sockets may fail *anywhere* in your code, and Twisted
takes care of all details for you[2]. Simply Sweet.

Cheers,

[1] http://www.twistedmatrix.com/
[2] Of couse this is just *one* advantage of the Twisted framework...

PS.: No, I wasn't paid for this e-mail ;-)

--
Felipe.
Sep 12 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by magic man via .NET 247 | last post: by
1 post views Thread by gangesmaster | last post: by
reply views Thread by gangesmaster | last post: by
reply views Thread by gangesmaster | last post: by
reply views Thread by gangesmaster | last post: by
9 posts views Thread by semedao | last post: by
1 post views Thread by Jeffrey Barish | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.