由于同步通信导致线程过多
我在 python 中同时使用线程和 xmlrpclib 。我定期创建一堆线程来通过 xmlrpclib 完成远程服务器上的服务。问题是，有时远程服务器没有应答。这会导致线程永远等待它永远不会得到的响应。随着时间的推移，处于这种状态的线程数量会增加，并将达到系统上允许的最大线程数量（我使用的是 fedora）。 我尝试使用 socket.setdefaulttimeout(10);但由此产生的异常将导致服务器失效。我在服务器端使用了它，但似乎不起作用：/
知道如何处理这个问题吗？
I'm using threads and xmlrpclib in python at the same time. Periodically, I create a bunch of thread to complete a service on a remote server via xmlrpclib. The problem is that, there are times that the remote server doesn't answer. This causes the thread to wait forever for a response which it never gets. Over time, number of threads in this state increases and will reach the maximum number of allowed threads on the system (I'm using fedora).
I tried to use socket.setdefaulttimeout(10); but the exception that is created by that will cause the server to defunct. I used it at server side but it seems that it doesn't work :/
Any idea how can I handle this issue?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你正在做我通常所说的（最初是西班牙语xD）“快乐之路编程”。您应该实施您的程序来处理不希望发生的情况，而不仅仅是您希望发生的情况。
这里的线程仅显示了一个潜在的错误：您的服务器无法处理超时，并且实现是严格的，添加超时会导致服务器由于未处理的异常而崩溃。
更稳健地实现它：它必须能够承受异常，服务器不能因为客户端行为不当而死亡。如果您现在不解决此类问题，以后可能会遇到类似的问题。
You are doing what I usually call (originally in Spanish xD) "happy road programming". You should implement your programs to handle undesired cases, not only the ones you want to happen.
The threads here are only showing an underlying mistake: your server can't handle a timeout, and the implementation is rigid in a way that adding a timeout causes the server to crash due to an unhandled exception.
Implement it more robustly: it must be able to withstand an exception, servers can't die because of a misbehaving client. If you don't fix this kind of problem now, you may have similar issues later on.
看来您真正的问题是服务器挂起某些请求，并且如果客户端关闭套接字，服务器就会挂起 - 线程只是实现的副作用。如果我正确理解您的意思，那么解决此问题的唯一方法是修复服务器以响应所有请求，或者在网络故障时更加稳健，或者（最好）两者兼而有之。
It seems like your real problem is that the server hangs on certain requests, and dies if the client closes the socket - the threads are just a side effect of the implementation. If I'm understanding what you're saying correctly, then the only way to fix this would be to fix the server to respond to all requests, or to be more robust with network failure, or (preferably) both.