hypfvieh
commented
11 months ago Unfortunately it is called with _connectionError == null on a regular disconnect. This leads to an NPE and the pending calls are not terminated so that in turn the sender thread is not terminated.
Where?
When disconnect() or close() is called, the connection should be closed and all remaining calls should be answered or at least receive an Error. Therefore internalDisconnect() is called with null parameter to signal this is a ordered clean shutdown, no shutdown due to an DBus error.
So when bluetooth is hanging in some sort of timeout and your application quits, dbus-java tries it's best to signal that the requesting endpoint will disconnect now and that all remaining calls are canceled.
The only obvious annoyance here is that the ExecutorService for the Sending-Threadpool create non-daemon threads.
I will change that, there is no reason to use non-daemon threads and block anything.
GeorgBisseling
Version dbus-java-core-4.2.1.jar
When experimenting with bluez-dbus I observed that Thread [DBus Sender Thread-1] sometimes inhibits the Java process from terminating cleanly.
There was a pending Connect call to a bluetooth device.
The code in org.freedesktop.dbus.connections.AbstractConnection.internalDisconnect(IOException) is intended to terminate such pending calls.
Unfortunately it is called with _connectionError == null on a regular disconnect. This leads to an NPE and the pending calls are not terminated so that in turn the sender thread is not terminated.