Multiple jabref instances with 4.3 maintable-beta while Port 6050 is checked

[bernhard-kleine]

• I have tested the latest master version from http://builds.jabref.org/master/ and the problem persists

JabRef 4.1; Windows 7 6.1 amd64; Java 1.8.0_171
JabRef 4.3-dev--snapshot--2018-05-07--maintable-beta--35b068386

Steps to reproduce:

1. Run 4.1, run 4.3 on the same file...
2. do some group actions in 4.3
3. .data in the 4.1 file are lost when saving

I was very astonished to see in parallel to JabRef 4.1; Windows 7 6.1 amd64 ; Java 1.8.0_171 JabRef 4.3-dev--snapshot--2018-05-07--maintable-beta--35b068386. Both programs have the port 6500 checked and tell me that only one instance of jabref would be running. I think an error of the snapshot version which does not respect that an instance of jabref is already running.

Port is blocked
        java.net.BindException: Address already in use: JVM_Bind
	at java.net.DualStackPlainSocketImpl.bind0(Native Method)
	at java.net.DualStackPlainSocketImpl.socketBind(Unknown Source)
	at java.net.AbstractPlainSocketImpl.bind(Unknown Source)
	at java.net.PlainSocketImpl.bind(Unknown Source)
	at java.net.ServerSocket.bind(Unknown Source)
	at java.net.ServerSocket.<init>(Unknown Source)
	at org.jabref.logic.remote.server.RemoteListenerServer.<init>(RemoteListenerServer.java:26)
	at org.jabref.logic.remote.server.RemoteListenerServerThread.<init>      (RemoteListenerServerThread.java:18)
	at org.jabref.logic.remote.server.RemoteListenerServerLifecycle.open(RemoteListenerServerLifecycle.java:43)
	at org.jabref.JabRefMain.start(JabRefMain.java:163)
	at org.jabref.JabRefMain.lambda$start$0(JabRefMain.java:57)
	at java.awt.event.InvocationEvent.dispatch(Unknown Source)
	at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
	at java.awt.EventQueue.access$500(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.awt.EventQueue$3.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

[bernhard-kleine]

Even Jabref4.1 starts to run when 4.3 is running.

[tobiasdiez]

Can confirm this issue with the maintable-beta branch.

[bernhard-kleine]

Why has this been closed. In the fresh 4.3 release this is not corrected: I could open two instances of 4.3.

[koppor]

@bernhard-kleine It was an automatism of GitHub, because @tobiasdiez referenced this issue in commit bb0f728.

This commit did not make it into the release, but in the development versions.

We are now working full steam ahead towards JabRef v5.0x. You can try the development version at https://builds.jabref.org/master/.

Maybe, in your case, it is better to use the v4.x development line, where we backport fixes from the 5.0 series to 4.x: You can get them from https://builds.jabref.org/v4.x/

[koppor]

For testing this issue, we ask you to run JabRef--v4.x--latest.jar together with JabRef--master--latest.jar to ensure you have the latest development versions. We are afraid, we are currently not heading to backport fixes to older v4 versions (such as v4.1).

[bernhard-kleine]

With jabref 4.1 I do not have this problem. I will test 4.x. What is the Bonus using this? Since import from jabfox was broken some time ago, my import from the internet is via PMID of pubmed. Since the bulk of citations have been added that is more convenient than using DOI since the entry with doi is not the full entry you get with PMID searching.
BTW do you have a solution for a keyboard shortcut for "next entry" and "previous entry"?

[tobiasdiez]

This should be fixed in the latest development version. Could you please check the build from http://builds.jabref.org/master/. Thanks! Please remember to make a backup of your library before trying-out this version.

[bernhard-kleine]

Running the version in master there could be two instances of the program. Not fixed at all.
JabRef 4.4-dev--snapshot--2018-06-04--master--ee669a542
Windows 7 6.1 amd64
Java 1.8.0_172

There could also be other versions of Jabref running in parallel. All of them have the port 6??? checked.

[tobiasdiez]

Mea culpa, you are right.

[Siedlerchr]

Maybe related to the Threading bug which does not shutdown correctly after JabRef exit?

[bernhard-kleine]

That could well be. With 4.3 I could see multiple jabref instances in the task manager. They had to be stopped manually.

[Siedlerchr]

Unfortunately still valid in current master snapshot

Second instance throws an exception but still starts:
17:30:19.067 [JabRef - Remote Listener Server on port 6050] ERROR org.jabref.FallbackExceptionHandler - Uncaught exception occurred in Thread[JabRef - Remote Listener Server on port 6050,5,main] - java.lang.IllegalStateException: Could not start JabRef with arguments []
	at org.jabref.gui.remote.JabRefMessageHandler.handleCommandLineArguments(JabRefMessageHandler.java:17)
	at org.jabref.logic.remote.server.RemoteListenerServer.handleMessage(RemoteListenerServer.java:62)
	at org.jabref.logic.remote.server.RemoteListenerServer.run(RemoteListenerServer.java:42)
	at org.jabref.logic.remote.server.RemoteListenerServerThread.run(RemoteListenerServerThread.java:32) 

[bernhard-kleine]

with the newest snapshot I could open to different screens of jabref 5.0 dev while the port 6050 is checked.

[Siedlerchr]

Should be fixed in the latest development version now https://builds.jabref.org/master

[bernhard-kleine]

@Siedlerchr , unfortunately not. I could open two instances:
There was however, an error message, but the second instance opened anyhow.

[Siedlerchr]

I restared the build, there was a temporary error. The new version should be the one with 46d2c7d

[bernhard-kleine]

Seems to be okay. A second instance starts but is suppressed and removed from the Windows taskmanager as it should be. Thank you.