【问题标题】:gevent.Timeout not raisedgevent.Timeout 未引发
【发布时间】:2013-03-28 20:29:29
【问题描述】:

我有一个服务器在一个部分中执行“一些事情”,并且我有一个“with gevent.Timeout(5)”围绕它。我在另一个greenlet中进行了一些检查,通过它我注意到其中一个执行“某些事情”的greenlet运行了45分钟。我最终不得不重新启动程序来杀死它(我知道其他杀死它的方法,但这不是问题......)。

我也使用 gevent.monkey.patch_all() 进行修补。 “一些东西”部分确实涉及网络连接,我猜有些东西卡在其中一个地方。我不明白为什么没有引发超时异常。有谁知道为什么可能没有引发 gevent.Timeout 异常?

【问题讨论】:

    标签: python network-programming timeout gevent monkeypatching


    【解决方案1】:

    每当我使用gevent.Timeout 时,我也将它用作上下文管理器,但使用第二个参数False。这样,上下文管理器会抑制任何异常并只留下代码块。您可以通过检查块是否成功设置值来跟进:

    result = None
    with gevent.Timeout(5, False):
        # Something that stalls
    
    if result == None:
        # Take care of business
    

    这对我来说非常可靠。似乎exceptiongevent.Timeout 的默认第二个参数是None——您是否尝试将其替换为您自己的异常类型?甚至Exception

    【讨论】:

    • 我认为将第二个参数设置为 False 或 None 应该不会有所作为?在 with gevent.Timeout 块之后,我有一个 return 语句,所以很明显我的代码被卡在了那个块的某个地方。我不能使用 if result == None: 语句。我无法在本地再次产生问题。那是在生产服务器中。我可以尝试自己的异常,但我必须能够再次产生问题,即使可以,我想知道我的异常会被抛出,因为它一开始并没有超时。
    • 一个与时间一样古老的故事 :-) FWIW,我们花了一点时间修补gevent.Timeout,最后使用False 并检查None,结果为我们。如果您的网络通信是 http 获取,我可以为您指出一些可以帮助您重现超时的单元测试。
    • 这不是 http 请求,而是与数据库的连接,我强烈感觉这与套接字有关。如果使用 makefile,我在 gevent 中发现了另一个与套接字超时相关的错误 - link。但可以肯定的是,检查你的单元测试是什么样的以及我是否可以在本地重现问题会很有帮助。我不明白为什么使用 False 应该锻炼。也许我自己也应该再调查一下。
    猜你喜欢
    • 2013-03-20
    • 1970-01-01
    • 1970-01-01
    • 2012-10-10
    • 2021-05-23
    • 2020-05-15
    • 2011-06-05
    • 2019-03-02
    • 2023-03-09
    相关资源
    最近更新 更多