Fix NetworkChecker hangs on Linux (See #10824)

[joshmoore]

Rather than attempting to connect to o.org.uk from Linux clients,
we attempt to use the Java 1.6 classes via reflection. If the
client is running on Java 1.5, the network is always assumed to
be up. This may cause deadlocks on changing networks for
Linux+Java 1.5 users, which will have to be clearly outlined in
the release notes.

For the more far more common cases, however, this should be work.

[jburel]

System.err.println("Failed during reflection. Assuming network is up.");
then returned value is false that implies that the network is down

[joshmoore]

@jburel: thanks, I'll push a commit in just a second. @zeb also had suggestions. Would it be easy to get access to a Logger instance?

[jburel]

@joshmoore: The problem, as the code stands, is that the class is in the util package and classes in that packages should not have reference to the env package and the logger object is in the env package.

[joshmoore]

@jburel: understood. Then I won't worry about that for the moment.

[joshmoore]

Note: travis failure is a timeout.

[ghost]

I've tested this on Debian (linux v3.9), with

• sun java5
• openjdk6
• openjdk7

Behaviour for 6 and 7 is the same, pulling the network cable and attempting some action results in the popup message that there has been a loss of connectivity, and plugging it back in resumes the action. 5 is similar, but there's an exception printed to the terminal at startup, and there's not popup message (but the action silently resumes on restoring connectivity).

However, in all three cases, there are bugs for certain actions, where there is no popup message, and the action is not resumed, or there's inconsistent behaviour. Examples include clicking the ROI tool in the image viewer, and the "add tag" button in the main browser. I tested on OS X with java6 to compare, and for these two examples the popup message appears, and it resumes correctly, so it certainly appears that the buggy behaviour here is linux-specific.

[joshmoore]

@rleigh-dundee: if those tests were straight-forward enough, it might be interesting to see a comparison with the behavior in 4.4.7, i.e. with the Socket check to o.org.uk.

@jburel: is there anything you can think of that we should examine now that the Socket check is gone?

[jburel]

@joshmoore: now that the blocker is sorted I will probably hold off for the 1.5 specific issues., we still have some calls to review that will not trigger the pop up I am aware of 2 or 3 so if @rleigh-dundee could list the one you notice on linux that will be useful but I will not consider as "blocker" for a 4.4.8 release

[ghost]

Testing with the official 4.4.7 release using the same java versions as above. All java versions show a delay of several minutes before the loss of network connectivity dialogue pops up, compared with a second or two with the new version. Additionally, the chance of recovery after reconnecting the network is far less likely, though sometimes does occur. Replugging before the message pops up generally results in resuming successfully, but after is a bit of a lottery. If anything, late resuming worked more reliably with java 5 than 6 or 7.

Unlike the new version, there's no exception at startup with java 5.

So the new version is definitely more responsive and more reliable, but as noted above does contain a few places where it's possible to lock up the UI, and this isn't much changed from the 4.4.7 release.

[joshmoore]

Thanks for the testing, @rleigh-dundee. Merging. I'll leave https://trac.openmicroscopy.org.uk/ome/ticket/10824 open for the RFEs.

[jburel]

The new version should be more responsive. 1.5 limitation on dev_4_4
We should probably turn the 1.6 code in develop since that will be the minimum requirement
Steps:

• Fix UI freeze (both)
• 1.6 code (develop only)

[mtbc]

Does this need any rebasing, given #1278 and the Java 1.6 requirement?

[jburel]

the plan is to re-activate the code compatible for Java 1.6 so no need to rebase that PR

--no-rebase