Experimental Physics and
Industrial Control System

<[email protected]> · Wed, 13 Aug 2014 10:03:11 +0000

Hi Michael,

> Beware.  NSLS2 started out this way, but eventually switched away due
> to
> performance problems (lack of caching mixed with the linking container
> widget).

Thanks for the warning, we will be making heavy use of the linking container widget so will avoid http. Would it be a good idea for us to look at caching to increase performance?

> Happily, while it isn't obvious, simply referencing files by absolute
> system path works.  We have a read-only copy of all .opi files
> accessible on each system.

Interesting, I thought only eclipse project paths could be used in opi links, this is certainly useful to know...

> So read-only access doesn't need workspace setup (which no one seems
> able to automate).  

I just found a useful link in the documentation:
http://cs-studio.sourceforge.net/docbook/ch05.html#idp347408

This would appear to be exactly what I need, as it creates projects and links within projects for me. I could then put all the path management in a wrapper script that then calls CS-Studio with a long -share_link argument. My updated diagram would then look like this:

workspace/ # located in user's home directory
  CSS/
  ID1/            # Eclipse project in user's workspace
    motorApp_opi/ # Eclipse link to /dls_sw/.../motor/6-5/motorApp/opi/opi
  ID2/            # Eclipse project in user's workspace
    motorApp_opi/ # Eclipse link to /dls_sw/.../motor/6-7/motorApp/opi/opi

I tried it out, and it created me new projects and links within those projects in an existing workspace, so it seems to do what I want. Have you used this method?

> We have a wrapper script which uses symlinks to select a version of the
> executable, and a customized preference file (which includes the path
> to
> the main .opi).

Could I have a copy of this wrapper script please?

> We still haven't completely dealt with the shared workspace problem.
> To
> mitigate this, our wrapper script keeps track of which computer a
> workspace is used from.  Attempts to start from a different machine
> give
> a prompt and the option to terminate the running session (via ssh).

After talking to the GDA guys, I think we will start out by creating a default workspace in the home directory of the user (which is NFS mounted on multiple machines), but setting osgi workspace locking = no and see if having multiple instances writing to the same workspace causes us any problems. As we aren't storing much apart from projects full of links at the moment, it might be ok... Have you tried turning off workspace locking?

Thanks,
Tom Cobb

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System