Re: [PATCH BlueZ] mesh: Log D-Bus method call errors

["michal.lowas-rzechonek@silvair.com" <michal.lowas-rzechonek@silvair.com>]

Hi Brian,

On 08/29, Gix, Brian wrote:
> That is true, and we *expect* applications that are attached to handle
> the socket-signals (that drive d-bus) in a timely manner...  But I am
> not sure we have a way to enforce it.
> 
> Certainly, we can simulate a disconnection if an App ignores it's DBus
> socket signal, but again, we won't know about that for 30 seconds
> which seems like forever...  And an App could potentially have a large
> enough backlog of messages negatively affecting the daemon before it
> and corrects it.

This seems like a limitation of ELL:
1. There doesn't seem to be an explicit API to set timeouts on method
   calls, so if the application takes too long to handle method calls,
   message_list hashmap in l_dbus struct would indeed grow quite large.
2. There doesn't seem to be a way to set an upper limit of pending
   messages (or maybe even message rate?) in l_dbus connection.

Still, looking at ell/dbus.c, it seems it should be possible to manually
call l_dbus_cancel after obtaining serial number of the method call
message, using _dbus_message_get_serial from dbus-private.h (yeah, I
know).

Anyway, I think a better approach would be to submit patches to ELL
implementing these two features, and then use these additions in meshd.
Does that sound acceptable from your POV?

By the way, it seems that bluetoothd suffers from the same problem with
regards to external GATT services/characteristics/descriptors.

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND