23.6.1. VMXi LIMS Agent¶
This secton contains information about the VMXi Laboratory Information Management System (LIMS) Agent.
23.6.1.1. Overview¶
ISPyB is used to store all information regarding plate locations and
status, so the Sample Handling process frequently makes
requests and updates to ISPyB whilst running. The
Data Collection process also makes requests to retrieve
requested diffraction plans, and perform updates during and after data
collections. It is useful for the GDA Client to be able to display information
regarding currently active plates and experiments, so requests are made to a
server side state monitor (monitoring.plates.VmxiStateMonitor) object that
would also be making requests of ISPyB.
The LIMS Agent was developed to wrap calls to the ISPyB Java API (which, in turn, reflects ISPyB Stored Procedures), providing a simple object whose methods provide the ISPyB interactions required by VMXi.
The interface implemented by the agent classes is the Lims interface, contains the two main implementations; the LimsAgentVmxi (representing calls to ISPyB) and the LimsAgentMock (a dummy implementation with information held in-memory).
The data classes used by the Lims interface, their resulting implementations
and relations to ISPyB are described here:
VMXi GDA Data Structures.
23.6.1.2. Auto-reconnect¶
While the connection to the database has proven very reliable, there is an auto-disconnect policy in place should a connection be inactive for an extended period of time (~8 hours). Since it is entirely plausible for the beamline to be inactive for such a duration, and as an added level of robustness, a Jython wrapper attempts to reconnect in the face of a failed call before trying again. The retry is made only once.
The wrapper developed is lims.LimsAgentReconnect. A single instance
of this agent is instantiated in localStation.py to be passed to the
relevant consumers.
A minor downside of this strategy is that all methods that make a call to ISPyB must now acquire a lock to do so; but we do not expect this to be a concern.
23.6.1.3. Caching¶
For reasons of simplicity, views on the GDA Client that display data relating to plates and experiments simply poll the server side monitor object. As multiple clients may exist, each with multiple views updating 5-10 times a second, this generates many more requests to ISPyB than originally imagined.
Calls to the LIMS Agent made by the Sample Handling and Data Collection processes should always receive up-to-date information (the results should always be fresh). However, it is not important for the GDA Client to receive such fresh values, and so it is entirely reasonable for results of calls to the LIMS Agent to be cached for a short period of time, avoiding unnecessary requests, as it is likely many of these calls will be for the same information. A simple Time-to-live (TTL) cache, with a timeout of only a few seconds, prevents excessive requests and alleviates concerns regarding multiple active clients/views. A maximum cache size and a Least Recently Used (LRU) cache replacement policy prevents excessive memory consumption and ensures stale calls ultimately get cleared away. As an aside, it is also possible for calls made via the two main processes to update the cache with their known fresh values, so the information displayed by the client doesn’t appear to lag behind the beamline’s operation.
The following wrappers have been implemented:
lims.LimsAgentCached- the object created inlocalStation.pywraps the previously mentioned auto-reconnecting object, and is passed to the state monitor object.lims.LimsAgentForceUpdate- the object created inlocalStation.pywraps the caching object and is passed to the Data Collection and Sample Handling processes, and is also the object used by staff on the Jython command line under the namelims.
The LIMS caching data flow is shown below.
