JabRef opens multiple instances even when Remote operation is enabled

JabRef version

Latest development branch build (please note build date below)

Operating system

GNU / Linux

Details on version and operating system

Linux Mint 20.1 MATE, JabRef 5.6–2022-04-04–dbf921e

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

1. Read documentation on this feature at https://docs.jabref.org/advanced/remote
2. Open JabRef
3. Under Options -> Preferences, Network, check the “Listen for remote operation on port” box and make sure 6050 is entered.
4. Save the settings, optionally restart the application.
5. Using netstat -lpnt |grep 6050 confirm that the port is properly opened by the java process
6. Attempt to open an additional copy of JabRef, either by launching the application or by using the browser extension to import a new reference.

Expected behavior: based on the documentation saying “Binding to this port makes it possible for a second JabRef instance to discover that the first one is running. In this case, unless specifically instructed to run in stand-alone mode, the second JabRef instance will pass its command line options through the port to the first JabRef instance, and then immediately quit.” (emphasis added).

Actual behavior: When importing from the browser extension, a new instance of JabRef is opened and stays open. When launched from a console, WARN: Port is blocked: java.net.BindException: Address already in use is shown in the console of the second JabRef instance, and the application opens and stays open.

Appendix

…

Log File

Apr 07, 2022 2:32:20 PM com.sun.javafx.application.PlatformImpl startup
WARNING: Unsupported JavaFX configuration: classes were loaded from 'module org.jabref.merged.module', isAutomatic: false, isOpen: true
2022-04-07 14:32:21 [JavaFX Application Thread] org.jabref.logic.net.ssl.TrustStoreManager.createTruststoreFileIfNotExist()
INFO: Trust store path: /home/jakkarth/.local/share/ssl/truststore.jks
2022-04-07 14:32:22 [JavaFX Application Thread] org.jabref.logic.remote.server.RemoteListenerServerLifecycle.open()
WARN: Port is blocked: java.net.BindException: Address already in use
	at java.base/sun.nio.ch.Net.bind0(Native Method)
	at java.base/sun.nio.ch.Net.bind(Unknown Source)
	at java.base/sun.nio.ch.Net.bind(Unknown Source)
	at java.base/sun.nio.ch.NioSocketImpl.bind(Unknown Source)
	at java.base/java.net.ServerSocket.bind(Unknown Source)
	at java.base/java.net.ServerSocket.<init>(Unknown Source)
	at org.jabref@5.6.144/org.jabref.logic.remote.server.RemoteListenerServer.<init>(Unknown Source)
	at org.jabref@5.6.144/org.jabref.logic.remote.server.RemoteListenerServerThread.<init>(Unknown Source)
	at org.jabref@5.6.144/org.jabref.logic.remote.server.RemoteListenerServerLifecycle.open(Unknown Source)
	at org.jabref@5.6.144/org.jabref.logic.remote.server.RemoteListenerServerLifecycle.openAndStart(Unknown Source)
	at org.jabref@5.6.144/org.jabref.gui.JabRefMain.handleMultipleAppInstances(Unknown Source)
	at org.jabref@5.6.144/org.jabref.gui.JabRefMain.start(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Unknown Source)
	at java.base/java.security.AccessController.doPrivileged(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(Unknown Source)
	at org.jabref.merged.module@5.6.144/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
	at org.jabref.merged.module@5.6.144/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(Unknown Source)
	at java.base/java.lang.Thread.run(Unknown Source)

[jakkarth]

I bought a new hard drive with more space and spent a few hours working through that document getting the environment set up. It took a lot of work, though some of that was because my machine started from a bad state.

Anyway, I’ve replicated things as best I can while debugging the (second) instance of JabRef, and there is indeed a network timeout trying to connect to the first instance. I am at a loss to explain how it could possibly take longer than 0.2 seconds to establish a network connection to localhost.

So, I can confirm https://github.com/JabRef/jabref/issues/8653#issuecomment-1101812034, but I’m at a loss to explain it. Increasing the timeout hasn’t fixed the underlying problem, but has kept it from occurring on my machine. At this point I’m satisfied that the ping code is in fact executing, but I hate the unsolved mystery of why 0.2s isn’t sufficient.

I propose increasing the timeout to 1000 as @Siphalor suggested. I would also suggest catching the java.net.BindException: Address already in use and showing the user a friendlier message about the two potential causes: 1, another application is already using this port and they should pick a different one for JabRef, or 2, the timeout value wasn’t long enough for their circumstances, in which case we could suggest they file a bug with additional info.

Now that I have a local environment where I can actually make those changes, I’d be happy to make a MR. Thoughts?

[jakkarth]

PR created. This is my first time contributing to this project. I read through the contribution guidelines and I think I got them all, but I’m happy to fix anything I missed. Your patience is appreciated 😃