BEAST: changing JMS URL in communicator

[ThomasLohnert]

At ISIS, our users can change which instrument (beamline) our control interface is pointing at at runtime. When doing so, we need the AlarmClientCommunicator to be reinstantiated with the updated JMS URL for that instrument in order to receive and display the correct alarms. Currently we are forcing this by changing back and forth between two configurations which is a bit hacky. If not already present, we would like an easier way to update the URL, e.g. with a dedicated method for refreshing the communicator in the AlarmClientModel, or a way to set the URL in the communicator directly.

[kasemir]

You can change the alarm configuration, i.e. the name of the 'root' element, at runtime. From the UI, you do that via the alarm tree, which has a drop-down listing of all the available alarm configurations. The alarm table and area view will then show the changed configuration.

But at this time all configurations use the same RDB and the same JMS server. That was done on purpose, because it allows reporting on multiple alarm setups (and IOC log messages and CSS log messages and other JMS traffic). Similar, on the RDB side it's typically easier to just use the one enterprise RDB setup at your site instead of having to maintain multiple smaller RDBs, like one per beamline.

Especially if you want to look at multiple instruments, I assume from a central control room, doesn't it make more sense to have all instruments use a common RDB and JMS?

[ThomasLohnert]

Our setup is designed in a more decentralized way to allow instruments to run independently from each other in case of network outages. The client looks at one instrument at a time, with the ability to switch between them at runtime, where each instrument has its own database. Therefore the approach of having one central database and many different configurations does not work for us. We are happy to implement a solution ourselves, we'd just need to know under what conditions you would be willing to merge it in.

[utzeln]

On ITER we have similar requirements.

What we do is: 1/ make sure that in each local database we have unique IDs for the full setup by setting ranges, 2/ setup a general data wrapper in Postgresql which includes an empty database and defines proxy tables on foreign databases in order to provide a "unified" central view. The proxy tables inherit from the empty table which is queried by the client.

This way a client can see the message history of all distributed database in one place, and locally the user can have access to the local message history. Same thing for the alarm RDB.