astropy SAMP library waits for client before closing HTTP connection from HUB

[Mark Taylor]

On Thu, 26 Jun 2014, Hugo Buddelmeijer wrote:

> Hi Mark
> 
> [changed subject to perhaps catch astropy developers in the discussion]
> 
> On 2014-06-25 13:32, Mark Taylor wrote:
> > > I will improve the SAMP clients under my responsibility as well. It seems
> > > best
> > > to create a separate threads for interfaces controlling the software (UI,
> > > SAMP), which queues (time-consuming) actions in a main, interface-less
> > > thread
> > > doing the work. However, the new HUB behaviour is very useful for short
> > > programs like 'client1.py' and it protects 'good' clients from the 'bad'
> > > ones.
> > >
> > > Perhaps most clients separate their interface properly, hence nobody
> > > complaining so far.
> >
> > There is a bit more to say on this.  The thread handling is really
> > something that ought to get handled by the client toolkit (where
> > applicable), rather than requiring individual application
> > authors to think about it.  I attach a java class that uses JSAMP
> > to do the same as your client1.py.  If you run this with your client2.py
> > test, it behaves the same under both JSAMP and AstroPy hubs - i.e. no
> > unwanted delays.  The reason is that the JSAMP client toolkit turns
> > around the XML-RPC call immediately, by running the client's supplied
> > callback method in a separate thread.  Evidently SAMPIntegratedClient
> > doesn't do that, it calls the supplied client function in the HTTP
> > server thread, so that the XML-RPC HTTP response does not get sent
> > back to the hub until the client callback has completed.
> >
> > While I wouldn't necessarily call that a bug in the python client library,
> > it would be better if it did it like JSAMP.  Then, although in principle
> > badly-behaved clients could still cause trouble for the existing JSAMP
> > hub implementation, you wouldn't see the problems that you're
> > experiencing for normal astropy.vo.samp-based clients.
> >
> > I should think it would be possible (maybe even easy?) to make that
> > change in the astropy.vo.samp client code.  Any volunteers?
> 
> So there are three location where multi-threading can prevent a SAMP lock-up:
> 
> 1) In the SAMP HUB, like astropy,
> 2) In the SAMP client library, like JSAMP, or
> 3) In the client itself.
> 
> Perhaps it would be best to do it in both 1) HUB and 2) client library, since
> that maximizes compatibility.
> 
> Since my plan was to include it in 3) my own client, I might as well attempt
> to do it in 2) the astropy library directly. Doing so would be cleaner and
> perhaps not so much extra work.

Great.  I'm happy to advise from the SAMP side, but my python is
rather rusty, and I don't have any experience of handling threads
in python, which is why I didn't want to volunteer myself.

> However, I will probably not finish this for the 0.4 release of astropy,
> planned for earlier [sic] this month:
> https://github.com/astropy/astropy/wiki/Release-Calendar

It would be nice to get it in there if there's an upcoming release,
but as you way it looks like it's too late to make changes now, even
if we did it ASAP.

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/