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

Exception in connection thread when connection timeout is triggered in Linux environment #48

Closed jliang1010 closed 5 years ago

jliang1010 commented 5 years ago

Not sure this has been noticed by others. I am using dbus-java in Ubuntu 16.04 64-bit VM. This API has been used public static DBusConnection getConnection(DBusBusType _bustype) According to the code, the default AbstractConnection.TIMEOUT, which is 100 second, will be applied. However, when the timeout is triggered, the connection thread is throwing an exception like 2019-04-29 16:31:40.351 [FINE ] [org.freedesktop.dbus.connections.AbstractConnection disconnect] - Disconnecting Abstract Connection 2019-04-29 16:31:40.351 [FINE ] [org.freedesktop.dbus.connections.transports.UnixSocketTransport close] - Disconnecting Transport 2019-04-29 16:31:40.352 [FINEST ] [org.freedesktop.dbus.MessageReader close] - Closing Message Reader 2019-04-29 16:31:40.352 [FINE ] [org.freedesktop.dbus.MessageWriter close] - Closing Message Writer 2019-04-29 16:31:40.352 [SEVERE ] [org.freedesktop.dbus.connections.IncomingMessageThread run] - Exception in connection thread. org.freedesktop.dbus.exceptions.FatalDBusException: Underlying transport returned EOF (1) at org.freedesktop.dbus.connections.AbstractConnection.readIncoming(AbstractConnection.java:1048) at org.freedesktop.dbus.connections.IncomingMessageThread.run(IncomingMessageThread.java:39)

I suppose this is not an expected behavior. In order to continue to use dbus-java in my project, I have to use the other getConnection API which allows setting timeout to 0.

Any thoughts and suggestions regards this issue? Many thanks.

hypfvieh commented 5 years ago

It's a bit ugly that the connection exception is logged as ERROR when the disconnection was to be expected due to timeout.

I fixed it upstream, so exceptions will only be logged if the thread was not asked to be shutdown.

Anyway, this is just an bad log statement, but does not change the behaviour of the library in any way.

jliang1010 commented 5 years ago

Cool! This makes senses. We were using an old version (3.0.0) in our project, just recently planning to move on to newer development of this library. Before, there was no timeout by default so we are not handling timeout and reconnect. We were kind of misled by the exception we have seen. Timeout handling is actually what we need here.

Thank you very much for your quick reply anyway. :)