Bug: Mage/4064 refuses outside connections

[jamoore]

The exception thrown is ConnectTimeoutException which occurs as soon as Blitz attempts to access the proxy (e.g. prx.ice_id()).

This is due to missing bidirectional communication configuration in both the client and the server. Chapter 38 of the ZeroC manual explains both how to do this and its limitations.

The primary limitation for our usage is that the "fixed proxies" which get created are only of use in process. Since OMERO clients don't connect directly to IceStorm via Glacier2, there's no way to reuse the bidirectional connection.

Instead we will initially attempt to use a wrapper, routing the storm communication through the Blitz server and down to the client.

Similar configuration will be needed for all callbacks which come from the client:

components/blitz/resources $ git grep -E '\(.*[a-zA-Z][*].*\)'
omero/API.ice:      void subscribe(string topicName, Object* prx) throws ServerError;
omero/API.ice:      bool keepAlive(ServiceInterface* proxy) throws ServerError;  // SAFE; PASSED OUT OF SERVER
omero/Repositories.ice:            void transfer(string srcPath, Repository* target, string targetPath) // SAFE; PASSSED OUT OF SERVER
omero/Scripts.ice:            void registerCallback(ProcessCallback* cb) throws omero::ServerError;
omero/Scripts.ice:            void unregisterCallback(ProcessCallback* cb) throws omero::ServerError;
omero/Scripts.ice:            void requestRunning(ProcessorCallback* cb);
omero/Scripts.ice:            omero::RMap getResults(Process* proc) throws ServerError; // SAFE; PASSED OUT OF SERVER
omero/SharedResources.ice:                addProcessor(omero::grid::Processor* proc)
omero/SharedResources.ice:                removeProcessor(omero::grid::Processor* proc)

See:

• ​http://zeroc.com/doc/Ice-3.3.1/manual/Connections.38.7.html
• ​http://www.zeroc.com/forums/help-center/5661-ice-grid-endpoint-issues.html

[jmoore]

(In [7188]) see #2485 - tracking down server-side timeout

[jmoore]

(In [7190]) see #2485 - calling del on exceptions during createSession

[jmoore]

(In [7279]) Preventing login exceptions. See #2485

[jmoore]

This issue is going to require a significant rework and/or perhaps a patch to Ice. The current limitation is that if the client cannot be seen by the server, then many if not all callbacks will fail. (e.g ClientCallback, ProcessCallback, etc.) Pushing to unscheduled but as "blocker" so that this gets addressed as soon as possible.

[jmoore]

(In [7452]) Disabling setCallback for 4.2.0 (See #2485, #2558)

[jmoore]

Workarounds in Insight for 4.2.0:

• ​http://trac.openmicroscopy.org.uk/shoola/changeset/7533
• ​http://trac.openmicroscopy.org.uk/shoola/changeset/7535

[jmoore]

Moved to 4.2.1 because of a suspected workaround ("createObjectAdapterWithRouter") This, however, was shown to have further Ice-issues. First, Ice.stringToIdentity() on the output of routerPrx.getCategoryForClient() periodically throws an exception requiring one to create the Identity manually. Second, periodic close hangs. Holding off.

[jmoore]

From ​http://www.zeroc.com/forums/help-center/5418-bidir-links-cross-nat.html

A server can freely return proxies to a bidirectional client. The only limitation is that all of the proxies must resolve to the same connection; in general, this means the proxies should all refer to servants in the same object adapter. (The goal is usually for the client to have a single connection to the server, and using multiple object adapters in the server would require the client to create multiple connections.) The server must create the proxy for every callback object in the client. As shown in our Ice/bidir example, the client passes the identity of its callback object to the server, and the server creates the proxy that it uses to send callback requests. The server should not be requesting proxies from the client.

This is without Glacier2, but it may be a workaround for the issues that we've run into to

[jmoore]

Again, not something we can do in a point release. Pushing.

[jmoore]

Bumping this issue after the sprint6 cleanup since other issues were tangentially related (e.g. #3191). Also marking as a bug so it won't slip through the cracks.

[jmoore]

I've finally got ​a working demo and can now proceed to modify the OMERO callbacks.

[jmoore]

ProcessCallback (scripts) and CmdCallback (graphs) now have proper callbacks working on branch ​https://github.com/joshmoore/openmicroscopy/tree/2485-callbacks

I've tested both of those callbacks being passed in with Ice 3.3 via SSH port-forwarding and everything works exactly as expected. Other callback scenarios need to also be tested and possibly modified.

[jburel]

Moved from sprint 2012-04-24 (13)

[jburel]

Moved from sprint 2012-05-08 (14)

[jmoore]

This requires a bit more testing for processors/scripts, but should be quite straight-forward. One thing to remember is that the blocking methods should check one extra time via a poll before throwing LockTimeouts. With that, this should be good to go. Pushing to the next sprint.

[jmoore <josh@…>]

(In [a6dc3afddb9c6a8edba73be3a068f97e907e8d30/ome.git] on branch develop) Fix modulus logic in HandleI (Fix #8845, See #2485)

If there were too few steps, then an arithmetic exception
was being thrown leading to no callback reaching the client
within the tests expected 10 seconds.

We may should make the timeout try again with a poll
to be sure it wasn't a network or other issue.

[jburel]

Moved from sprint 2012-06-05 (16)

[jmoore]

Script callbacks and Handle callbacks are all now working as expected. Other proxies which are passed (like ClientCallback?) still need to be checked, lowering priority because everything that MUST function is now functioning.

[jmoore]

All the callback that we rely on for client functionality are currently working (chgrp, processor). ClientCallback seems not to be working, at least not for heartbeats, but that may be a server-side issue. But, that is not a required feature.

Therefore, I'm closing this as fixed. The only caveat would be that if during the testing of RC1 we realize there are any problems with the DeleteCallbackI, I would suggest we move it to use CmdCallbackI which I have locally.

[Jesse Corrington <jesse.corrington@…>]

(In [5e1223fe907595f1bcb8682099ace43bda3d52be/ome.git] on branch develop) Make callbacks work across a firewall. see #2485

The object adapter needed to be created with the router, as it's done in Python