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

[Hugo Buddelmeijer]

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.

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

Hugo


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3257 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.ivoa.net/pipermail/apps-samp/attachments/20140626/19d49f0d/attachment-0001.bin>