Improve SNS live listener behaviour when asking for start of run when we are not in a run

[Russell Taylor]

In #6661, we decided that if you ask for data from the start of the run when the instrument is not in a run, then the listener would just throw an exception, causing StartLiveData to fail. This is actually pretty unpleasant, especially when using the listener behind some interface other than the StartLiveData one. What would be better is if the listener just waited until a run did start, and then start passing back the events. The reason we didn't do this before is that we didn't want things to just lock up, potentially indefinitely, for the start of a run that never came - since the listener isn't able to check for a cancellation signal.

It has occurred to me that we could do this by creating a specific exception type and having the listener throw that in this situation (instead of throwing a general exception type, which just stops the algorithm). LoadLiveData could catch this exception, log it, check for cancellation and then call extractData() once again a few seconds later.

[Russell Taylor]

Re #7785. A new exception type for use by live listeners.

This will allow listeners to pass control back to LoadLiveData rather than blocking if not ready to return a workspace. This will allow things like algorithm cancellation. Unlike other exceptions it will not stop the algorithm.

Changeset: 303193062a6857ed75c7dfa08fcadc2a5900a796

[Russell Taylor]

Re #7785. The algorithm side of waiting for a run to start.

LoadLiveData catches the NotYet exception, logs it and waits 10 seconds before calling extractData() again. While waiting it listens for user cancellation of the algorithm. Listeners can throw this exception to 'pause' things - any other exception type will stop the algorithm. LoadLiveData had to be made a 'proper' child of StartLiveData for the cancellation signal to get through.

Changeset: b6566768c52455504592d0d7c03cc6717bd7fff8

[Russell Taylor]

Re #7785. Hooks for testing the use of the NotYet exception.

Add a property to have the FakeEventDataListener throw the NotYet exception a given number of times. This allows testing of the behaviour on the algorithm side of this work.

Changeset: 105bd3a7d2b8b01b52cbeec27b81eab2158238ac

[Russell Taylor]

Re #7785. SNS listener throws a NotYet exception when appropriate.

In particular, it throws it if data was requested from the start of the run but the instrument is not in a run. This allows the user to cancel the algorithm or wait until a run starts, at which point the data will flow. It will also throw if the workspace has not been initialized, though not immediately as experience shows that it can sometimes (SEQUOIA for example) take some time for the instrument to be loaded.

Changeset: 11430e0ef79768249f11387ad4a6585359463809

[Russell Taylor]

Tester: The branch is feature/7785_snslistener_out_of_run_behaviour

Test by going to Load -> Live Data and choosing 'Start of Run' as the starting time.

Real-world functional testing on this could be tricky as it relies on HYSPEC or SEQUOIA not being in a run (look for 'Stopped' as the status at ​https://monitor.sns.gov/dasmon/). The other way to test is to use the FakeEventDataListener, adding a property 'fakeeventdatalistener.notyettimes = N' to your Mantid.user.properties, where N is the number of times the listener should say that it's not ready to return data. Make sure that you can cancel the algorithm when you see the message about being 'not ready to return data'. Also make sure data collection does start after the specified number of these messages (or when a real instrument actually does start a run).

[Russell Taylor]

It would probably also be wise to check things for ISIS. The steps would be:

• Change default facility to ISIS
• Start the FakeISISHistoDAE algorithm
• Start live data collection, using the ISISHistoDataListener

[Alex Buts]

Fake data listener with fakeeventdatalistener.notyettimes works as described.

ISIS histo data listener does not communicate with FakeISISHistoDAE regardless of FakeISISHistoDAE existence failing with error:

Error accessing DAE DAE is not connected Error in execution of algorithm LoadLiveData: DAE is not connected in 0.0.0.0 Unable to successfully run ChildAlgorithm LoadLiveData Error in execution of algorithm StartLiveData: DAE is not connected in 0.0.0.0

As I suspect something wrong in DAE configuration rather then anything else, I am giving this ticket pass.

[Alex Buts]

Merge remote-tracking branch 'origin/feature/7785_snslistener_out_of_run_behaviour'

[Stuart Campbell]

This ticket has been transferred to github issue ​8630