search

hypfvieh / dbus-java

Improved version of java DBus library provided by freedesktop.org (https://dbus.freedesktop.org/doc/dbus-java/)
https://hypfvieh.github.io/dbus-java/
MIT License
185 stars 73 forks source link

Message ordering not maintained #133

Closed simon-lgb closed 3 years ago

simon-lgb commented 3 years ago

I've noticed that notifications sent from a BLE device in rapid succession arrive in the wrong order. As far as I know, the order of sent notifications should be guaranteed, so I consider this to be a bug with dbus-java. After some testing, I've tracked the cause down to AbstractConnection#handleMessage(DBusSignal, boolean). The received DBusSignals are in the correct order. That ordering of received messages is lost due to the use of a thread pool for dispatching the signals to their handlers. I'd create a pull request with a fix, but I am unsure what the best solution for this problem would be while also maintaining performance. I'm not very familiar with multithreading.

hypfvieh commented 3 years ago

This is a known problem when using multi-threading and it is not easy to fix. I had a discussion about that last year in the bluez-dbus bugtracker (see #27).

If message order is important for you, change the thread-pool size to 1 (connection.changeThreadCount(1)).

simon-lgb commented 3 years ago

Thanks for the quick reply! I didn't find the other issue before. That solved my problem and the performance impact is actually minimal. So if I understand you correctly and you currently don't see a way of fixing this more permanently, I guess this issue can be closed.

hypfvieh commented 3 years ago

If this would be easy to fix, I would have fixed it a while ago. But that is the price for using multithreading, nobody guarantees that the thread which receives the first signal has finished processing before the second thread has finished the second signal. I've already thought about a number of possible workarounds, but none of them seem to be a good solution. They will probably always slow down processing or will just move the ordering problem to another piece of code.

So for now, the problem is still existing and can be worked around by setting the threadpool size to 1.