Is nrjavaserial still maintained?

ssalonen · March 1, 2020, 4:57pm

Hi all,

It looks like nrjavaserial fork used by openHAB is not patched against a certain race condition fixed in the upstream project: https://github.com/NeuronRobotics/nrjavaserial/commit/f010deeb3c0367f469be338f3edf8f6528322063

Compare that to openHAB implementation:

github.com

openhab/nrjavaserial/blob/master/src/main/java/gnu/io/RXTXPort.java#L1101


                        if (debug)
                                z.reportln( "RXTXPort:close( " + this.name + " ) leaving"); 
                } catch( InterruptedException ie ) {
                        // somebody called interrupt() on us
                        // we obbey and return without without closing the socket
                        Thread.currentThread().interrupt();
                        return;
                }
                finally
                {
                    IOLockedMutex.writeLock().unlock();
                }


	}




	/** Finalize the port */
	protected void finalize()
	{
		if (debug)
			z.reportln( "RXTXPort:finalize()");

An user seemed to hit this bug as reported here: Problem with modbus binding with dynamic on/off

I noticed that there are no issues enabled in the openhab/nrjavaserial. Is it still maintained or how is it kept up-to-date with upstream?

Bruce_Osborne · March 1, 2020, 5:04pm

@Kai What is the status here?

Kai · March 1, 2020, 5:15pm

I don’t know, I guess we are waiting for a 3.16.0 release, which isn’t there yet.
@wborn might know more about the diffs as the PR referred to above is from him.

wborn · March 1, 2020, 6:22pm

We stopped using the openhab/nrjavaserial fork and instead now use the same code as NeuronRobotics/nrjavaserial but with some different compiler options with this wborn/nrjavaserial-builder.

The 3.15.0.OH2 version we use already has a couple of additional commits compared to the official nrjavaserial 3.15.0 release. Most notably the arm64 support I added upstream.

I can build a 3.15.0.OH3 version so it also contains the additional PRs I made (the IllegalMonitorStateException fix and properly named threads which is also nice).

Because this is an openhab-core dependency the only way to get it integrated into 2.5.x would either be a new openhab-core 2.5.x release (which is frozen) or adding some overrides to openhab-distro 2.5.x which I think is also not preferable @Kai?

The easiest fix might be to catch the IllegalMonitorStateException. For OH3 we need a new version anyways because nrjavaserial crashes on Windows when using Java 11 (nrjavaserial#131, openhab-core#1384). I might help out with that if it hasn’t been resolved by the time users start testing OH3.

Kai · March 1, 2020, 7:03pm

Indeed, I would only want to do this for really critical issues, which imho isn’t really the case here. Let us focus on getting an up-to-date Java11-compatible version for 3.0.

ssalonen · March 2, 2020, 4:45pm

Thank you both. Understand the reasoning here and makes sense.

I will still check if this error is causing any side effects (e.g. Unclean port close, preventing re-opening the port), but if not, I agree it is of low priority.

rossko57 · March 11, 2020, 11:39am

This may be another manifestation in another binding. What should be a recoverable error becoming a port blocked.

wborn · April 14, 2020, 10:46pm

There’s a PR for updating nrjavaserial to the official 3.20.0 release in OH3 now which should fix the IllegalMonitorStateException, see:

system · May 26, 2020, 2:46pm

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.