You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When registering more than ~250 objects on ubus, calling ubus list on the command line hangs before finishing to list all the registered objects. It keeps waiting for data and the //sequence end message// on the socket forever.
This issue was witnessed on x86 VM builds of Chaos Calmer and LEDE 17.01.4 as well as ubus on a Linux Desktop. The number of objects being successfully listed varied for each system (232 for CC VM, 252 for LEDE VM and 572 on Desktop).
The root of the problem seems to be a limitation of the ubus daemon. When doing a recursive lookup, one message per object is sent from the daemon to the client. The current implementation of the ubus daemon seems to discard messages, when the fixed size tx queue is full.
The code responsible for this behavior can be found in method ubus_msg_enqueue() in ubusd.c:
if (cl->tx_queue[cl->txq_tail])
return;
Calling one or more methods in rapid sequence could potentially lead to the same problem.
The text was updated successfully, but these errors were encountered:
I'd like to raise the priority on this task. It's critical to our plans for the prplMesh project, where we're aiming to expose a big data model on ubus.
We're currently running into this limitation, and blocked on it.
marv:
When registering more than ~250 objects on ubus, calling
ubus list
on the command line hangs before finishing to list all the registered objects. It keeps waiting for data and the //sequence end message// on the socket forever.This issue was witnessed on x86 VM builds of Chaos Calmer and LEDE 17.01.4 as well as ubus on a Linux Desktop. The number of objects being successfully listed varied for each system (232 for CC VM, 252 for LEDE VM and 572 on Desktop).
The root of the problem seems to be a limitation of the ubus daemon. When doing a recursive lookup, one message per object is sent from the daemon to the client. The current implementation of the ubus daemon seems to discard messages, when the fixed size tx queue is full.
The code responsible for this behavior can be found in method ubus_msg_enqueue() in ubusd.c:
if (cl->tx_queue[cl->txq_tail]) return;
Calling one or more methods in rapid sequence could potentially lead to the same problem.
The text was updated successfully, but these errors were encountered: