event sending is being retried and later failed with zerorpc.ChannelMultiplexer, unable to route event

[Shiplu Mokaddim]

Hello everyone, 

I am having this issue for nowadays. It seems when I call a method of the server, from the client end zerorcp retries to send the underlying the event. Check this logs

     1 2019-10-28 19:25:45,508 : [DEBUG  ] zerorpc.events::connect : connected to tcp://private-server:10000 (status=None)

     2 2019-10-28 19:25:45,509 : [DEBUG  ] remoteplanningapi::__init__ : _id = ac8795a5-00e2-4778-fece-f1ce7fe9b775

     3 2019-10-28 19:25:45,509 : [DEBUG  ] remoteplanningapi::remove_vehicle : RPC<<: remove_vehicle(vehicle={'id': '467af87f-038d-41ec-be59-f57038e7c32a'})

     4 2019-10-28 19:25:45,509 : [DEBUG  ] zerorpc.channel::new_event : --> new channel b'59b99f0fe87646aba52e806761995b9a'

     5 2019-10-28 19:26:00,510 : [DEBUG  ] zerorpc.channel::close : -x- closed channel b'59b99f0fe87646aba52e806761995b9a'

     6 2019-10-28 19:26:02,512 : [DEBUG  ] remoteplanningapi::remove_vehicle : RPC<<: remove_vehicle(vehicle={'id': '467af87f-038d-41ec-be59-f57038e7c32a'})

     7 2019-10-28 19:26:02,512 : [DEBUG  ] zerorpc.channel::new_event : --> new channel b'59b99f10e87646aba52e806761995b9a'

     8 2019-10-28 19:26:07,553 : [WARNING] zerorpc.channel::_channel_dispatcher : zerorpc.ChannelMultiplexer, unable to route event: <b''> ERR {'response_to': b'59b99f0fe87646aba52e806761995b9a', 'message_id': b'f569c2f870fb4750a50c03608dc84db3', 'v': 3} [...]

     9 2019-10-28 19:26:07,913 : [DEBUG  ] zerorpc.channel::close : -x- closed channel b'59b99f10e87646aba52e806761995b9a'

On line 1 we connect to the server. And on line 2 we call a method remove_vehicle of the server. Zerorprc creates a channel with id 59b99f0fe87646aba52e806761995b9a and sends the method call as an event on line 4. Then it closes the channel. But after that we don't get a response that we try again. But this time we get an error "zerorpc.ChannelMultiplexer, unable to route event". What does that mean? How can we prevent this?

How do we know that the event was received successfully by the server and currently being processed? If it's acknowledged by server then we can stop retrying.

I hope the problem was clear to you. If not, I'm up for more information.

[Shiplu Mokaddim]

Hello again, 

I believe I have some more information now. When the first event was sent it was taking long time for server to process. Actually longer than our retry-timeout. We retried after 17 seconds. but the first call was 22 seconds long. That means when we called for the second time the response was in the channel and that caused  'unable to route event:' erorr?

Am I right? What is the recommended way to handle this?