VOspec - killer of SAMP

[Mark Taylor]

Petr,

On Sat, 25 Apr 2015, Petr Skoda wrote:

> Hi all
> 
> investigating the issue about SAMP in multiuser environment I have found the
> mess caused by VOspec (version 6.6) even in single-user environment.
> 
> The issue is this.
> 
> I have had used during my VO lectures within last two weeks many many times
> examples sending VOtables between Topcat Aladin and Splat-VO in different
> combinations until I decided to run VOspec.
> After quiting it and other running apps I was not able to start SAMP again !!
> 
> Every of this Big Three apps (aladin, topcat, splat) did have in Interop menu
> ONLY PLASTIC. It means the window of plastic does not have ability to run SAMP
> hub . Good by - SAMP - no way to run it again.
> The issue is finally very simple explained.
> 
> The start of VOspec (6.6. tested only) creates the .plastic lock file
> 
> (here is example :
> 
> #PLASTIC server uk.ac.starlink.plastic.ServerSet
> #Sat Apr 25 00:11:43 CEST 2015
> plastic.xmlrpc.url=http\://castor\:2117/
> uk.ac.starlink.plastic.servid=uk.ac.starlink.plastic.ServerSet at 11905c5
> plastic.version=0.4
> plastic.rmi.port=1104
> 
> )
> 
> This file is not removed even after correct finishing VOspec.
> 
> So when it exists - from now on ANY apps does not show SAMP window anymore
> (the VOSpec only has both menus)
> I guess thats because the SAMP in VOspec is obsolete or has strange logic not
> common to other apps ....

Thank you for this investigation and report.  There is presumably an
issue as you say with VOSpec not clearing up after itself properly,
but also improvements should be made to the code in TOPCAT and SPLAT
(I'm responsible in both cases), and maybe Aladin and other
PLASTIC-and-SAMP-capable applications, that works out whether
to try to run in SAMP or PLASTIC mode.

At present, TOPCAT and SPLAT look to see if there's a ~/.plastic
lockfile and if so they assume they are in PLASTIC land.
It sounds like Aladin may do something similar.  That probably was
a good assumption when the code was written (several PLASTIC
applications available, SAMP just being introduced) but it's not now,
since as far as I know PLASTIC is pretty much moribund.
I will adjust the logic in TOPCAT so that it only runs in PLASTIC
mode if you explicitly request that (with the -plastic flag).
So in future releases, regardless of whether VOSpec deletes its
.plastic file or not, you won't see a corresponding problem in
TOPCAT.  I will also talk with Peter and Margarida about making
the corresponding changes in SPLAT.  Maintainers of other
SAMP-and-PLASTIC-capable tools might like to look at their code too.

If anybody knows of cases where PLASTIC is still in use,
and thinks that changing application behaviour in this way
(explicit configuration required for PLATIC use)
might cause trouble, please speak up.

> I am sure that there will be other VO apps issues in interoperability when
> someone really starts to use them . I am just wondering how it is possibl
> ethere was so many schools and training ongoing in the world but no-one had
> noticed the mis-behaviour of the interoperability which as been our buzzword
> for 15 years ;-)
> 
> Not talking that general behaviour of VO apps is basically horrible - during
> 20 hours of intensive VO hands-ons in three universities we have suffered at
> least 10 times the crash of all of them (even Topcat ;-)
> from unknown reasons - usually it was during tim ewhen I was not clicking on
> anything or loading tables.
> 
> We have used different OS (linux, mac, several windows) some java was openjava
> in linux some were genuine Oracle 1.7 or 8 ....
> 
> No difference

I'm sorry about this.  We do our best.  When users report a crash
with enough detail to work out what might be going wrong
(steps to reproduce it, stack trace, description of what kind of
"crash" it was or what else was going on at the time) I try hard
to identify the problem and fix it.  "Unknown reaons" is a bit
difficult to work with, though I do appreciate that while running
a tutorial it may not be feasible to submit detailed bug reports.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/