So I'm working on a TCP in python.
We are having a problem with threads not exiting properly.
We want it to have multiple connections, so when a new connection is spawned a new thread is started. However these threads don't always exit properly. They have return statements but when I run Thread.activeCount() I find that these build up.
I have no idea what the problem is. These threads build up, and then dissipate. I want to do a thread time out, however I don't want to use Thread.join() because if a new connection is established it won't go to the receive functions, which would cause the client to timeout due to a lack of response.
Any suggestions on a timeout command? I can't seem to find any on the python docs.
Related
Title says it all really. I am running a program on a Linux EC2 instance with 4 threads. Three of these are listening to different websockets and the final one is webscraping and calling off a set of other functions when needed.
Is it possible that if the GIL is owned by the 4th thread (i.e it is currently running its calculation through the single core) that websocket messages could be 'missed' by the threads listening?
I am beginning to think it isn't possible, but have no understanding as to why. I have looked around, but to little avail.
Not really, even if your application is completely blocked say by scheduling or simply sleeping the operating system will queue the incoming network messages. You might lose messages say if the TCP buffer starts to overflow, I reckon that is unlikely in your case. You can test your idea by deliberately sleeping in the 4th thread for some time and see if messages are dropped.
When using time.sleep(1) before sendMessage, the hole process stops (even the others connections).
def handleConnected(self):
print self.address, 'connected'
for client in clients:
time.sleep(1)
client.sendMessage(self.address[0] + u' - connected')
Server: https://github.com/dpallot/simple-websocket-server
How to solve it?
The server that you are using is a synchronous, "select" type server. These servers use a single process and a single thread, they achieve concurrency through the use of the select() function to efficiently wait for I/O on multiple socket connections.
The advantage of select servers is that they can easily scale to very large number of clients. The disadvantage is that when the server invokes an application handler (the handleConnected(), handleMessage() and handleClose() methods for this server), the server blocks on them, meaning that while the handlers are running the server is suspended, because both the handlers and the server run on the same thread. The only way for the server to be responsive in this type of architecture is to code the handlers in such a way that they do what they need to do quickly and return control back to the server.
Your handleConnected handler function is not a good match for this type of server, because it is a long running function. This function will run for several seconds (as many seconds as there are clients), so during all that time the server is going to be blocked.
You can maybe work around the limitations in this server by creating a background thread for your long running task. That way your handler can return back to the server after launching the thread. The server will then regain control and go back to work, while the background thread does that loop with the one second sleeps inside. The only problem you have to consider is that now you have sort of a home-grown multithreaded server, so you will not be able to scale as easily.
Another option for you to consider is to use a different server architecture. A coroutine based server will support your handler function as you coded it, for example. The two servers that I recommend in this category are eventlet and gevent. The eventlet server comes with native WebSocket support. For gevent you have to install an extension called gevent-websocket.
Good luck!
You are suspending the thread with sleep and the server which you are using seems to be using select to handle the requests not threads. So no other request will be able to be handled.
So you can't use time.sleep.
Why do you need to sleep? Can you solve it some other way?
Maybe you can use something like threading.Timer()
def sendHello(client):
client.sendMessage("hello, world")
for client in clients:
t = Timer(1.0, lambda: sendHello(client))
t.start() # after 30 seconds, "hello, world" will be printed
This is off the top of my head. You would also need a way to cancel each timer so I guess you would need to save each t in a list and call it when done.
In my (python) code I have a thread listening for changes from a couchdb feed (continuous changes). The changes request has a timeout parameter which is too big in certain circumstances (for example when a user wants to interrupt the program manually with ^C).
How can I abort a long-running blocking http request?
Is this possible, or do I need to reduce the timeout to make my program more responsive?
This would be unfortunate, because having a timeout small enough to make the program really responsive (say, 1s), means that there are lots of connections being created (one per second!), which defeats the purpose of listening to changes, and makes it very difficult to make sure that we are not missing any changes (in the re-connecting timespan we can indeed miss changes, so that special code is needed to handle that case)
The other option is to forcefully abort the thread, but that is not really an option in python.
If I understand correctly it looks like you are waiting too long between requests before deciding whether to respond to the users or not. You are right continuously closing and creating new connections will defeat the purpose of changes feed.
A solution could be to use heartbeat query parameter in which couchdb will keep sending newlines to tell the client that the connection is still alive.
http://localhost:5984/hello/_changes?feed=continuous&heartbeat=1000&include_docs=true
as long as you are getting heartbeats (newlines) you can be sure that you are getting new changes. A new line will indicate that no changes have occurred. Where as an actual change will be reported back. No need to close the connection. Respond to your clients if resp!="/n"
Blocking the thread execution in general prevents the thread from beeing terminated. You need to wait until the request timed out. But this is already clear.
Using a library that supports non blocking requests is maybe a solution, but I don't know if there is any.
Anyway ... you've mentioned that reducing the timeout will lead to more connections. I'd suggest to implement a waiting loop between requests that can be interrupted by an external signal to terminate the thread. with this loop you can control the number of requests independent from the timeout.
I am using python 2.7 and Mysql. I am using multi-threading and giving connections to different threads by using PooledDB . I give db connections to different threads by
pool.dedicated_connection().Now if a thread takes a connection from pool and dies due to some reason with closing it(ie. without returning it to the pool).What happens to this connection.
If it lives forever how to return it to the pool??
No, it does not. You have to tell the server on the other side that the connection is closed, because it can't tell the difference between "going away" and "I haven't sent my next query yet" without an explicit signal from you.
The connection can time out, of course, but it won't be closed or cleaned up without instructions from you.
Not sure if I have myself a problem with a python script I'm using.
Basically, it spawns threads, each creating a tcp connections.
Well the script finishes, i even check if any threads are still functioning, all of them return False ( not active which is good).
The issue is that, if I check ( I use CurPorts from nirsoft ) some tcp connections ( between 1 and 9 sometimes ) are still in established status and sometimes in Sent status.
Is that a problem ?They die out eventually, but after several minutes.
IS that on python's side fault, or basic windows procedure?
I close the sockets with S.close, if that's of any help. I'm not using daemon threads, just simple threads, and I just wait until all of them finish (t.join())
I need to know i I should worry or just let them be. reason is that they are eating up the ephemeral port number, and besides that i do not know if its keeping resources from me.
Would appreciate a noob friendly response.
Last Edit: I do use S.shutdown() before I send S.close()
I do not do any error checking though, I have no idea how to go about doing that besides try:
The simple answer is that TCP connections need to be gracefully shutdown before being closed.
There are more details on how to call shutdown and close there:
How do you close TCP connections gracefully without exceptions?
socket.shutdown vs socket.close
http://msdn.microsoft.com/en-us/library/ms738547(VS.85).aspx