workman-json-rpc 調(diào)用服務(wù)時(shí)好時(shí)壞，異常recvData empty，不是超時(shí)，無報(bào)錯(cuò)！急?。。?
第一次接觸workman-json-rpc,調(diào)用服務(wù)的時(shí)候有時(shí)候會(huì)返回recvData empty，時(shí)好時(shí)壞。超時(shí)時(shí)間我設(shè)置的15秒，但是每次都很快返回recvData empty，跟蹤代碼，發(fā)現(xiàn)是RpcClient.php文件里的recvData方法，fgets返回false(connection是正確的)，請(qǐng)問可能是什么導(dǎo)致的。
3個(gè)回答
打賞
應(yīng)該是連接斷開了，一般是業(yè)務(wù)代碼發(fā)致命錯(cuò)誤，或者業(yè)務(wù)代碼調(diào)用了exit、die導(dǎo)致。
如果發(fā)生致命錯(cuò)誤會(huì)在workerman.log里可以看到錯(cuò)誤日志。
發(fā)生問題的時(shí)候php start.php status 能看到一些信息進(jìn)程退出碼信息
-
alenshu 2018-12-24感恩解答，我看只要出錯(cuò)，日志里拋出的就是pid:25765 worker[JsonRpc:25871] exit with status 11，翻看到了類似的帖子，這個(gè)原因是用了不穩(wěn)定php擴(kuò)展導(dǎo)致的嗎（裝的擴(kuò)展沒變，以前一直用的hprose-rpc直接調(diào)用的沒有問題），還有可能是其他原因嗎
你這個(gè)問題我也遇到過，還有一種可能就是：
Services里的業(yè)務(wù)運(yùn)行超時(shí)了【即超過了?RpcClient::TIME_OUT】，對(duì)于RpcClient來說， RpcClient::TIME_OUT意味著服務(wù)端的業(yè)務(wù)必須在?RpcClient::TIME_OUT 內(nèi)將數(shù)據(jù)給我扔回來，否則客戶端會(huì)關(guān)閉連接。
?
-
alenshu 2018-12-24
感恩解答，我看錯(cuò)誤日志里顯示的pid:25765 worker[JsonRpc:25871] exit with status 11，請(qǐng)問這個(gè)錯(cuò)誤碼是因?yàn)椴环€(wěn)定的php擴(kuò)展導(dǎo)致的嗎，感謝
-
phpcreeper 2018-12-24
@5200: exit with status 11 表明進(jìn)程收到了 SIGSEGV 信號(hào)，SIGSEGV代表在POSIX兼容的平臺(tái)上，SIGSEGV是當(dāng)一個(gè)進(jìn)程執(zhí)行了一個(gè)無效的內(nèi)存引用，或發(fā)生段錯(cuò)誤時(shí)發(fā)送給它的信號(hào)。
據(jù)此推測最大可能的原因是：
1、使用了不穩(wěn)定的PHP擴(kuò)展導(dǎo)致內(nèi)存泄漏；
2、程序本身可能導(dǎo)致的內(nèi)存泄漏，比如使用了類的靜態(tài)數(shù)組； -
alenshu 2018-12-24
感謝指導(dǎo)，起先還以為以為是zookeeper擴(kuò)展的問題，刪掉了RpcClient里改造的代碼，后來發(fā)現(xiàn)是因?yàn)轫?xiàng)目里還繼承了hprose-rpc的service，去掉就好了，感謝感謝
狀態(tài)圖如下
-
-
alenshu 2018-12-24
@1:感謝指導(dǎo)，找到了問題，因?yàn)轫?xiàng)目里還繼承了別的rpc服務(wù)端導(dǎo)致的，去掉就好了，還有一個(gè)問題。
我提供的服務(wù)不用static也可以正常跑，看文檔上說服務(wù)方法也要定義成static,請(qǐng)問如果方法不換成static的會(huì)有別的影響嗎 -
-
