當eta達到時，連續多次執行長eta（8+小時）的芹菜任務

我創建了一個範圍在3到20小時之間的eta任務，當我查看工作日誌時，執行此任務，工人在收到原始任務後每小時說「Got task from broker: ...」，直到達到eta。當eta達到時，連續多次執行長eta（8+小時）的芹菜任務

我知道這與設置BROKER_TRANSPORT_OPTIONS = {'visibility_timeout': X}有關，其中X是以秒爲單位的數字。

所以我玩visibility_timeout，如果我把它設置爲小於1小時，然後我可以看到工人每X秒獲得相同的任務，但是當我設置visibility_timeout到X大於1小時然後它保持不管我設定的時間，默認爲1小時。

有沒有其他人遇到這個問題？這是一個知道的錯誤？

我用芹菜3.0.11（Chiastic幻燈片）與Redis的服務器版本2.4.15

我剛剛也遇到了這個bug，運行Celery v.3.0.19和Redis服務器v.2.4.6，但即使在與Redis服務器運行在同一臺機器上的工作人員也發生了這種情況。 – oiez

同時觀察。芹菜== 3.0.21 django-celery == 3.0.21 Python 2.7.3，Redis服務器版本2.2.12。。在同一臺機器上運行。 –

即使Redis和工作人員在同一臺計算機上運行，也遇到了celery 3.1.17，Redis服務器2.8.4的這個錯誤。 –

編輯：任何消息消費者使用海帶*連接到相同的Redis URL 將有助於恢復UNACKED消息，因此，你必須確保所有的都配置了相同的visibility_timeout值。

一個常見的錯誤是開始花箴言是這樣的：

celery flower -b redis://somewhere

，而不是像這樣：

celery -A proj flower

因爲前者意味着花實例不會與芹菜配置中配置，然後缺少BROKER_TRANSPORT_OPTIONS和visibility_timeout設置。

除此之外，您還必須確保掛鐘使用ntp同步，如下面原始回覆中所述。

原答覆：

即使我沒有聽說過這樣的事，它可能是一個錯誤。我添加了一些打印語句到kombu/transport/redis.py來檢查visibility_timeout是否設置正確，這對我來說是絕對的。測試它的值大於一個小時將會花費更多的時間（大約2小時），所以我可以在那時報告。

在平均時間，你可以驗證你是（在Redis的運輸到例如restore_visible法）自行添加打印語句

注意，此功能是使用時間戳正確設置visiblity_timeout，因此，如果您有多臺機器時，重要的是時鐘幾乎是同步的（特別是不要在幾個小時內漂移）。您應該始終在聯網服務器上使用ntp並定期進行同步。

2012-10-02 12:25:35 asksol

我安裝了kombu/transport/redis.py，並且visibility_timeout確實設置正確。將redis服務器和芹菜工作人員移動到一臺機器上解決了這個問題。我檢查了以前的機器並且它們是同步的（例如，兩者上的系統時間和日期相同） – user1713317

用新的細節更新了答案！ – asksol

回答