Hanging EventNotifier Threads about calimero-core HOT 5 CLOSED

Thank you for your report!
Why would it prevent breaking the loop? Having entered wait is not a prerequisite for detecting the interrupt.

Do you maybe have a concrete example for when that happened?

from calimero-core.

From my understandings entering wait is a prerequisite to detect an interrupt in the loop trough an InterruptedException, since it's a method designed to throw one if interrupt is invoked. Sure, entering wait is in general not a prerequisite to detect an interrupt, but in this loop of the calimero project it is, because it will only stop on catching an InterruptedException. I got a concrete case of this problem in a large scale application, maybe i can find the time to give a reproducing example. Thanks for the quick reply, please let me know if further information to my explanation are needed.

from calimero-core.

As I see it, your problem can be described by the following sequence (producing an execution equivalent to the event notifier):

Thread.currentThread().interrupt();
System.out.println("thread interrupted = " + Thread.currentThread().isInterrupted());
final Object lock = new Object();
try {
	while (true) synchronized (lock) { lock.wait(); }
}
catch (final InterruptedException e) {
	System.out.println(e);
}
System.out.println("thread exit");

Which will exit the thread, and is in accordance with the expected behavior of wait.

So yes, please provide a stack trace, snapshot, or example where this fails, so I can see the root cause.

from calimero-core.

You were right on the behavior of the interrupt flag, my bad. I had the time to dig deeper and found the root cause of the issue i saw. It's connected to the openhab issue openhab/openhab1-addons#1068. We use a similar way of connecting to calimero: When the connection is lost, calimero fires a CloseEvent. Any attached NetworkLinkListener will be fired, in the current EventNotifier Thread. If the linkClosed method of such handles the disconnection, there is no problem. In this case the connection was also handled through that method call, which will keep the old EventNotifier Thread open and drive the application into the undefined state mentioned above. For reference, the issue can be solved by spawning the reconnect task in a new Thread, through a scheduled TimerTask for example. Thanks for your help, i'll close this issue since it was a wrong use of the library.

Greetings,
Marcel

from calimero-core.

Good to know it worked out, thanks for the feedback. (The problem you describe is basically a form of thread hijacking, which should in general be avoided.)

from calimero-core.