Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Fri, 2 Mar 2012 10:06:29 -0500

Hi:

I agree with Ralph that it's better to prevent concurrent use
of the same workspace.
I prefer a CSS product that initially asks for the workspace,
you have the option to "not ask again" and always use that one from then
on,
except when it's already in use you get a message:
Workspace in use, pick different one (or cancel).

But not everybody agrees.
Some sites use individual operator accounts in the control room,
log in and out for each shift.
Others use a generic "operator" account that all share, never logging out.
And so on, and that's fine, but it influences how you want to handle
your CSS startup: Prompt for workspace, because everybody is user
"operator" but since you're actually the user "Fred" you want
to use /usr/fred/MyWorkspace?
Or are you already logged in as "Fred", and just $HOME/Workspace
is correct, don't want to be prompted?

These are all part of the decisions you make when you create a CSS
product for your site:
Use SDS or BOY? CAJ or JNI JCA? Read archived data from Oracle, MySQL,
XML-RPC, ...?
Support a logbook? Allow sending emails?
... Lock the workspace? Prompt for workspace?

As for how you technically handle the workspace, the "common" startup code
has an extension point where you specify modules that handle
the various phases of the application startup.
One is the "workspace".

Since I now have at least one backer in Ralph,
I've updated the Basic EPICS product to use the same workspace
prompt that the SNS product uses, which basically just means
adding one line to its plugin.xml:

So future versions of the Basic EPICS product will
behave as described above and prevent the issues that
Ralph describes.

For your own product, you can implement the workspace handling
classes any way you want, just note that the code in there
must not by accident already activate the workspace while
you are in the process of determining which one you want to use.
That can for example happen when you call code from another plugin
that has preference settings, because to get the preference
settings Eclipse will activate some default workspace.

In case your workspace _does_ get corrupted,
in many cases all you need to do is:
Delete the ".metadata" directory.
All your files will still be there.
What's lost is
* the last window location - no big deal.
* your preferences modifications
  - should also not be a big deal because ideally
    the product for your site has all essential settings
    "built in", or you use a -pluginCustomization file
    that has them, so end users don't need to bother

    with EPICS CA addr list, archive data sources, ...

Thanks,
Kay

On 3/2/12 05:07 , "Ralph Lange" <[email protected]> wrote:
>n 01.03.2012 19:16, Kasemir, Kay wrote:
>> [...]
>> So for multiple instances:
>> Run CSS with different workspaces.
>> (Some versions allow you to actually use the same workspace,
>> they don't "lock" the workspace, but then don't complain if
>> you get strange results because multiple instances clobber
>> the same workspace files).
>
>Don't share the workspace.
>There is a *high* chance that you corrupt the workspace in a way that
>could a) freeze a currently running instance of CSS, b) make
>subsequently starting CSS instances immediately crash. I've been
>rebuilding workspaces from scratch a number of times because of this.
>
>One of the versions that allows silent workspace corruption is the
>generic "SNS Basic EPICS" version that (in principle) is recommended for
>non-SNS users. IMO, these versions are not improving the CSS reputation,
>and should be fixed to lock the workspace.
>
>~Ralph
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System