Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java gateway bugfixes #5513

Merged
merged 14 commits into from Nov 23, 2017
Merged

Java gateway bugfixes #5513

merged 14 commits into from Nov 23, 2017

Conversation

dominikl
Copy link
Member

@dominikl dominikl commented Sep 18, 2017

What this PR does

  • Guest login was used to determine if a username is actually a session id. With this PR a joinSession attempt is made, if the username matches UUID format.
  • The Facility.handleException() method silently 'swallowed' exceptions caused by connection issues. With this PR a DSOutofServiceException is thrown in these cases.
  • Adds JoinSessionCredentials to provide a specific class for session id logins.
  • Automatically remove stale connectors from the groupConnectorMap. That way the Gateway can continue working after a server restart without explicit dis- and reconnect.
  • Makes the Gateway AutoCloseable so that it can be used in try-with-resources blocks.
  • In various Facility methods, check arguments and return immediately when arguments not reasonable (Ids not provided, etc.).

Testing this PR

  • Check Java gateway integration tests.
  • Test that login via session id still works
  • Test that reconnect after connection loss still works. E. g. open Insight. Disconnect network. Try to browse a dataset. A connection warning should appear after a while. Reconnect the network. Insight should reconnect again, too, without crashing.
  • Continuously request some data from the server using the same Gateway connection (catch all exceptions). Stop and restart the server in between. While the server is not running you will get some exceptions. But when the server is ready again the Gateway should continue working as usual. See below for an example test client (*).

Related reading

--

*) Example client to use for testing server restart

LoginCredentials l = new LoginCredentials( ... );
Gateway g = new Gateway(new SimpleLogger());

ExperimenterData exp = g.connect(l);
SecurityContext ctx = new SecurityContext(exp.getGroupId());

while (true) {
    try {
        IObject obj = g.getFacility(BrowseFacility.class).findIObject(
                ctx, Image.class.getSimpleName(), 1);
        System.out.println(obj.getClass().getSimpleName() + " "
                + obj.getId().getValue());
    } catch (Throwable e) {
        e.printStackTrace();
    } finally {
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
        }
    }
}

@@ -142,7 +142,7 @@
public static final String PROP_STATELESS_SERVICE_CREATED = "PROP_STATELESS_SERVICE_CREATED";

/** Regex matching ICE Session ID */
private static final String ICE_SESSION_ID_REGEX = "[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}";
public static final String ICE_SESSION_ID_REGEX = "[a-f0-9]{8}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{4}-[a-f0-9]{12}";
Copy link
Member

@joshmoore joshmoore Sep 21, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting. Might be worth moving this to an Ice constant and using this server-side as well. To data, I've always treated the session IDs as opaque, i.e. no assumptions could be made.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The documentation says that each Ice object has an UUID and so does the session ID look like, although I didn't find anything in the documentation which explicitely says that the session ID is an UUID, too.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, actually I could also just use Java's builtin UUID.fromString() method.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

although I didn't find anything in the documentation which explicitely says that the session ID is an UUID, too.

Exactly. It's not yet part of the contract.

ExperimenterData root2 = gw2.connect(c2);
Assert.assertNotNull(root2);
Assert.assertEquals(gw2.getSessionId(root2), sessionId);
gw2.disconnect();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If something throws re: gw2, gw1 will not be closed which could hang the test.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could make the Gateway AutoCloseable ( c31e719 ), would make things easier. Any objections?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No objections. 😃

@dominikl
Copy link
Member Author

Just for reference, already noticed the problem with the 'swallowed' exceptions in 5.2 #4344 (comment) and Josh's idea of an 'ExceptionHandler', but forgot about it again. General exception handling overhaul would be a breaking change, but probably necessary, maybe for 5.5 then...

@@ -130,7 +130,7 @@
public Collection<DataObject> getHierarchy(SecurityContext ctx, Class rootType,
List<Long> rootIDs, Parameters options)
throws DSOutOfServiceException, DSAccessException {
if (rootType == null || CollectionUtils.isEmpty(rootIDs))
if (rootType == null)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rootIDs.isEmpty() case will go okay?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, same behaviour as roodIDs == null (get all).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, maybe also mention in Javadoc, just add "or empty" or something.

@dominikl
Copy link
Member Author

Not quite sure, ready to merge or relist for standup?

@mtbc
Copy link
Member

mtbc commented Oct 16, 2017

Has it yet had any functional testing?

@dominikl
Copy link
Member Author

Nope, doesn't look like it. I'll relist and maybe @pwalczysko can have a look when he can spare some time.

@pwalczysko
Copy link
Member

All the four bullet points from the "Testing this PR" header passed.
Ready to merge FMPOV

@joshmoore joshmoore changed the base branch from develop to clisplit November 21, 2017 10:55
@joshmoore
Copy link
Member

Thanks, @dominikl. At some point, it would be interesting to review your changes here against the Python Gateway (i.e. properly specifying the string format for the session ids, etc.) Merging into the clisplit branch for further testing.

@joshmoore joshmoore merged commit 48d5860 into ome:clisplit Nov 23, 2017
@joshmoore joshmoore added this to the 5.4.2 milestone Jan 16, 2018
@dominikl dominikl mentioned this pull request Feb 7, 2018
dominikl added a commit to dominikl/openmicroscopy that referenced this pull request Feb 7, 2018
With ome#5513 the java gateway removes stale connectors (e.g. after
server restart). So Insight can't use the gateway any longer to
provide the information which images are currently viewed, the
stale references are removed after server restart / reconnect.
@dominikl dominikl deleted the java_gateway_fixes branch April 16, 2018 12:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants