workerman\mqtt subscribe訂閱問題
根據(jù)官方示例
在 onWorkerStart的回調(diào)中進行創(chuàng)建mqtt客戶端，然后進行訂閱
但官方是訂閱一個topic
我現(xiàn)在的需求是以數(shù)組的方式進行多個topic訂閱，
數(shù)組來源于數(shù)據(jù)庫，
發(fā)現(xiàn)命令行運行之后，數(shù)據(jù)庫訂閱信息進行更新但是workerman創(chuàng)建的mqtt客戶端里面訂閱的仍然是之前的數(shù)據(jù)，
目前解決的辦法是手動reload命令行，
請問官方人員和其他有經(jīng)驗的大佬，這個問題如何在不重啟命令行的情況下進行處理。
也嘗試過如下代碼，但不知合不合理。希望官方給予回復。
如上，測試每10秒進行訂閱，訂閱信息確實能夠及時更新了，但是沒有測試其他功能是否正常，希望官方給予最佳實踐，感謝！
5個回答
剛才測了上述方法，訂閱是能更新了，但是onMessage回調(diào)沒有執(zhí)行，一直在執(zhí)行上面的循環(huán)。
-
2548a 2022-04-26只要你看過workerman開發(fā)必讀就不會問這種問題
7、不要使用exit die sleep語句業(yè)務執(zhí)行exit die語句會導致進程退出，并顯示W(wǎng)ORKER EXIT UNEXPECTED錯誤。當然，進程退出了會立刻重啟一個新的進程繼續(xù)服務。如果需要返回，可以調(diào)用return。sleep語句會讓進程睡眠，睡眠過程中不會執(zhí)行任何業(yè)務，框架也會停止運行，會導致該進程的所有客戶端請求都無法處理。
9、業(yè)務代碼里不要有死循環(huán)業(yè)務代碼里不要有死循環(huán)，否則會導致控制權無法交還給workerman框架，導致無法接收處理其它客戶端消息。
-
感覺這個邏輯有問題，onConnent是連接回調(diào)，不應該在這里面訂閱。訂閱是阻塞任務。
我認為應該是另起一個進程訂閱，收到數(shù)據(jù)后通知已連接的客戶端?？蛻舳诉B接成功后可以把需要通知的客戶端ID放到redis，然后保持在線就可以。訂閱進程拿到數(shù)據(jù)后查redis看需要給哪個客戶端推送。
個人理解，不一定對，僅限參考
也考慮過使用 Timer 一段時間后執(zhí)行命令行重啟
但這樣涉及到liunx用戶權限以及操作處理是否成功或者異常等問題，沒有深入研究過，測試在Worker的onWorkerReload回調(diào)成功執(zhí)行，但依然覺得并不是最佳實踐。
- 暫無評論
onWorkerStart里用定時器
\Workerman\Timer::add(10, function(){
$this->subscribe(Handle::getSubscribe());
});-
-
-
walkor 2022-04-26死循環(huán)影響，因為workerman得不到進程控制權，無法執(zhí)行onmessage。定時器執(zhí)行完歸還控制權，workerman就可以監(jiān)聽觸發(fā)onMessage
-
-
-
