No reply within specified time

[lunasaw]

Hello, I reported this error when I was executing a Bluetooth connection, and I failed to try the connection multiple times. What is the reason for this exception being exposed?

org.freedesktop.dbus.errors.NoReply: No reply within specified time
at org.freedesktop.dbus.RemoteInvocationHandler.executeRemoteMethod(RemoteInvocationHandler.java:202)
at org.freedesktop.dbus.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:89)
at com.sun.proxy.$Proxy237.Connect(Unknown Source)
at com.github.hypfvieh.bluetooth.wrapper.BluetoothDevice.connect(BluetoothDevice.java:389)
at com.weidian.app24h.iot.plugin.bl.ConnectDeviceHelper.connect(ConnectDeviceHelper.java:398)
at com.weidian.app24h.iot.plugin.bl.ConnectDeviceHelper.connect(ConnectDeviceHelper.java:220)
at com.weidian.app24h.iot.plugin.bl.ConnectDeviceHelper.connect(ConnectDeviceHelper.java:97)
at com.weidian.app24h.iot.plugin.bl.CabinetCommandHelper.authDevice(CabinetCommandHelper.java:62)
at com.weidian.app24h.iot.plugin.common.task.AuthBlueTimerTask.processGetStatus(AuthBlueTimerTask.java:89)
at com.weidian.app24h.iot.plugin.common.task.AuthBlueTimerTask.run(AuthBlueTimerTask.java:46)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)

[hypfvieh]

I can't tell you anything you won't already see in the stacktrace.

A method which expects a return value is called on the bus but did not return in time.
The default timeout is 20 seconds. When the call takes longer than that, this exception is thrown.

I can't tell you why you don't get any answer, just that you don't get one.

[lunasaw]

I can't tell you anything you won't already see in the stacktrace.

A method which expects a return value is called on the bus but did not return in time. The default timeout is 20 seconds. When the call takes longer than that, this exception is thrown.

I can't tell you why you don't get any answer, just that you don't get one.

Sorry, I don't understand the calling logic of dbus very much. Where can I judge the exceptions here? 20s, where can I set this configuration? Is the connection timeout?

[lunasaw]

I can't tell you anything you won't already see in the stacktrace.

A method which expects a return value is called on the bus but did not return in time. The default timeout is 20 seconds. When the call takes longer than that, this exception is thrown.

I can't tell you why you don't get any answer, just that you don't get one.

This should be the exception of getting isConnected after calling Connect

[hypfvieh]

The timeout can be changed using MethodCall.setDefaultTimeout(). This should only be called ONCE before you start your connection. The used timeunit is milliseconds. So you may use 60000 or something like that for longer wait times.

Anyhow, I highly doubt that this will fix the problem. It is more likely that your bluetooth device is not responding.

[lunasaw]

The timeout can be changed using MethodCall.setDefaultTimeout(). This should only be called ONCE before you start your connection. The used timeunit is milliseconds. So you may use 60000 or something like that for longer wait times.

Anyhow, I highly doubt that this will fix the problem. It is more likely that your bluetooth device is not responding.

After prolonged Bluetooth connections and frequent scanning, the memory usage of the dbus-daemon process gradually increases. Have you encountered this case before?

[hypfvieh]

I never measured. DBusDaemon is usually a system service and dbus-java is just a library to allow utilizing that service.
So I don't think that it really matters what the daemon is doing because it is not under my control.

DBus is used for a lot of things on Linux, almost every service which interacts with the user directly uses it. Bluetooth, NetworkManager, PulseAudio/Pipewire, Desktop Environments (Gnome, KDE, etc) - all of them use the dbus-daemon to communicate with one another.
And because it is such an essential piece of the system and has been around for 15 years or more, I would guess that it is well tested and heavily used, so that I also would not expect it to have memory issues like leaking memory and so on.