There is a list for AMB discussion now!
First, thanks to 01.org
and Intel for hosting the mailing list for
Automotive Message Broker. 0.11 is now beta which means only bug fixing
from here onward. The focus of 0.12 is performance and here are some of
the planned changes many of which have already landed in master:
- DBus signal fire rate throttled.
There is a new config option for the dbus sink plugin called "frequency".
This is how many times signals will be fired from the DBus. The reason is
that firing signals over DBus is very expensive in terms of CPU. The
frequency units are Hz, so if you want 100 signals per second, you would
enter "frequency" : "100".
- High speed data should not use DBus plugin
DBus is great for setting, getting data with security, but it's not great
for high speed data. It is recommended that applications use DBus for
getting single values and for setting and for low speed data changes. If
applications need high-speed data, they should use the new websocket plugin.
- New websocket plugin
The new plugin we could call "websocket2". It uses libwebsocket but the
protocol can be either Json or a binary protocol. It uses QJsonDocument
which is the fastest Json parser on the planet. Early benchmarks show it's
at least twice as fast as libjson-c and turning on the "binaryProtocol"
option inside the config makes it even faster.
We still have the old websocket plugin in the tree for now. We may remove
it in the future and recommend developers use the new websocket plugin.
PLEASE NOTE: the new websocket plugin has an updated json protocol.
- Dynamic DBus objects
In 0.11, all DBus object were created at startup. Application developers
where asked you use FindObject (and like methods) to discover the paths for
the specific objects they wanted. Because these objects where created at
startup, boot performance was impacted. Additionally, signals would fire
on these object whether or not any application would be listening. This
means that if the dbus sink received 1000 data updates per second, it would
fire 1000 over dbus even if no one was listening. In 0.12 the objects will
not be available on DBus until FindObject (and like methods) are called and
the object will stay "active" on DBus until the last process that called
FindObject has disconnected from DBus or closed.
This change in behavior will not break existing applications that are
already using FindObject. If an application is hard-coding the object path
(ie "/asdfa234234/0/VehicleSpeed") then those applications will break.
The combination of the above changes should have a huge impact on AMB
performance, especially when using DBus.
These performance issues are being tracked in the tizen ivi jira here:
Happy New Year! I'm looking forward to a very productive year in AMB