Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: CSS workspace lock, prompt Re: BOY FAQ
From: "Kasemir, Kay" <kasemirk@ornl.gov>
To: Ralph Lange <Ralph.Lange@gmx.de>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: 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:

<extension point="org.csstudio.startup.module">
...
  <workspace class="org.csstudio.sns.startuphelper.WorkspacePrompt"/>
...
</extension>

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" <Ralph.Lange@gmx.de> 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
>



Replies:
Re: CSS workspace lock, prompt Re: BOY FAQ Ralph Lange
Re: CSS workspace lock, prompt Re: BOY FAQ Michael Davidsaver
References:
Re: BOY FAQ Ralph Lange

Navigate by Date:
Prev: Re: QT-based tools: Expressions of interest requested Ned Arnold
Next: Re: CSS workspace lock, prompt Re: BOY FAQ Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: Re: BOY FAQ Ralph Lange
Next: Re: CSS workspace lock, prompt Re: BOY FAQ Ralph Lange
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·