amari: Fix Conn rx timeout handling
Conn multiplexes many requests/responses over single WebSocket connection. To do so it organizes dedicated receive thread that continuously receives messages from underlying websocket connection and dispatches received replies back to threads that issued corresponding requests. An rx timeout in that receive thread is thus not something unexpected - it can happen e.g. if there is simply no requests sent. But I missed that in 61ad9032 (amari: Add functionality to interoperate with an Amarisoft LTE service via WebSocket) and implicitly did not ignored such global rx timeout. As the result `amari xlog` does not work properly if period of requests is greater than timeout value, for example: $ xamari xlog ws://localhost:9001 ue_get/30s {"meta": {"event": "start", "time": 1670588996.0623107, "generator": "xlog ws://localhost:9001 ue_get[]/30.0s"}} {"meta": {"event": "service attach", "time": 1670588996.1852894, "srv_name": "ENB", "srv_type": "ENB", "srv_version": "2022-12-01"}} {"message":"config_get", ...} note {"message":"ue_get","ue_list":[],"message_id":2,"time":3045.323,"utc":1670588996.423} ----> {"meta": {"event": "service detach", "time": 1670589026.3569217, "srv_name": "ENB", "srv_type": "ENB", "srv_version": "2022-12-01", "reason": "timed out"}} {"meta": {"event": "service attach", "time": 1670589029.485363, "srv_name": "ENB", "srv_type": "ENB", "srv_version": "2022-12-01"}} {"message":"config_get", ...} {"message":"ue_get","ue_list":[],"message_id":2,"time":3078.606,"utc":1670589029.706} ... -> Fix it by ignoring global rx timeout. NOTE: we must also add manual handling of per-request timeout when waiting for corresponding reply. If we don't do that a situation where particular reply does not come back, but replies for other requests are coming back ok, will never be detected. Here is how fixed version works now: $ xamari xlog ws://localhost:9001 ue_get/30s {"meta": {"event": "start", "time": 1670589223.0339117, "generator": "xlog ws://localhost:9001 ue_get[]/30.0s"}} {"meta": {"event": "service attach", "time": 1670589223.1970558, "srv_name": "ENB", "srv_type": "ENB", "srv_version": "2022-12-01"}} {"message":"config_get", ...} {"message":"ue_get","ue_list":[],"message_id":2,"time":3272.292,"utc":1670589223.391} {"message":"ue_get","ue_list":[],"message_id":3,"time":3302.274,"utc":1670589253.373} {"message":"ue_get","ue_list":[],"message_id":4,"time":3332.266,"utc":1670589283.365} ... Note that ue_get messages are coming sequentially and there is no "service detach" event, that was artificially popping up due to wrong timeout handling.
Showing
Please register or sign in to comment