Skip to content

Enable short-name access to TestContext devices

Anton Joubert requested to merge issue-357 into develop

Easier client access during tests

When a device server is launched via the (Multi)DeviceTestContext, it is run without a Tango database. This means that access to any of its devices must be done via a fully qualified Tango Resource Locator (FQTRL). I.e., we need something like tango://172.17.0.3:48493/test/device/1#dbase=no, instead of just the short name: test/device/1. Requiring the FQTRL is inconvenient.

This change stores the test device server's FQTRL in a global variable while the TextContext is active. Then, in order to make device access with short names transparent, the DeviceProxy, AttributeProxy and Group classes have been modified to take this global variable into account. If it is set, and a short (i.e., unresolved) TRL is used for the proxy constructor or group add method, then the name is rewritten to a fully qualified (resolved) TRL. If this FQTRL is not accessible, the short name is tried again (except for Group) - this allows real devices to be accessed via short TRLs, if necessary.

Limitations:

  • Group patterns (* wildcard) are not supported.
  • Group device names will be FQTRLs, rather than the short name that was originally supplied.
  • Launching two TestContexts in the same process will not work correctly without FQTRLs. The TestContext that is started second will overwrite the global variable set by the first.

There should not be a noticeable performance degradation for this outside of test environments. It it just a single variable lookup per proxy constructor or group add invocation.

This new TestContext functionality is enabled by default. It can be disabled by setting the enable_test_context_tango_host_override attribute to False before starting the TestContext.

Port detection

As before, if the user doesn't specify a port number when instantiating the TestContext, omniorb will select an ephemeral port automatically when the device server starts. We need to determine this port number before any device calls its init_device method, in case it want to create clients (DeviceProxy, etc.) at that early stage.

The solution to this is the addition of a pre_init_callback in the server.run and server.Device.run_server methods. This is called after Util.init() (when omniorb has started and bound to a TCP port for the GIOP traffic, and the event system has bound two ports for ZeroMQ traffic), but before Util.server_init (which initialises all classes in the device server).

During pre_init_callback the TestContext probes the process's open ports to determine the GIOP port number. We didn't find a way to determine the port number without probing each port.

Closes #357 (closed)

Edited by Anton Joubert

Merge request reports