JSAMP HUB waits for callee before returning to caller

[Mark Taylor]

Hi Hugo.

On Wed, 25 Jun 2014, Hugo Buddelmeijer wrote:

> JSAMP_async indeed behaves better as far as my concerns went. I did not test
> the shutdown functionality.

Thanks.  I will wait for some experience from users in other contexts
before deciding whether to incorporate this change into the release.

> 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. I noticed the delays before, but SAMP was not a high
> priority for me at that time and waiting a few seconds is usually not so bad
> because you need the action performed anyway. However, our recent SAMP
> experiments, with two clients sending messages back and forth autonomously,
> failed spectacularly because each client was waiting on the other to close the
> HTTP session, resulting in a lock-up of the entire system.

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?

> Also great to see that JSAMP is on github now. Since I had never used JSAMP
> stand-alone (always through TOPCAT webstart), I went through the IVOA website
> to (not) find it.
> 
> The IVOA twiki
>   http://wiki.ivoa.net/twiki/bin/view/IVOA/SampSoftware
> still links to
>   http://software.astrogrid.org/doc/jsamp/
> which links to google
>   https://code.google.com/p/astrogrid/
> for the source repository.
> 
> Perhaps the IVOA twiki should be updated to point to
>   http://www.star.bristol.ac.uk/~mbt/jsamp/
> ?

Well spotted!  I fixed the link, thank you.

> (It being a wiki, I finally decided to make an account, but it seems you need
> to have an account in order to make one, so this failed.)

If it's actually not possible to get an account on the IVOA wiki,
that's bad.  Can you either complain to ivoadoc at ivoa.net, or give
me the details of what you tried and didn't work, and I'll do it for you.

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/
-------------- next part --------------

import java.util.Map;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.astrogrid.samp.Message;
import org.astrogrid.samp.Metadata;
import org.astrogrid.samp.Response;
import org.astrogrid.samp.Subscriptions;
import org.astrogrid.samp.client.ClientProfile;
import org.astrogrid.samp.client.DefaultClientProfile;
import org.astrogrid.samp.client.HubConnection;
import org.astrogrid.samp.client.HubConnector;
import org.astrogrid.samp.client.MessageHandler;

public class Client1 {

    public static void main( String[] args ) throws InterruptedException {
        Logger.getLogger( "org.astrogrid.samp" ).setLevel( Level.WARNING );
        ClientProfile profile = DefaultClientProfile.getProfile();
        HubConnector connector = new HubConnector( profile );
        Metadata meta = new Metadata();
        meta.setName( "JavaClient1" );
        connector.declareMetadata( meta );
        connector.addMessageHandler( new DelayMessageHandler() );
        connector.declareSubscriptions( connector.computeSubscriptions() );
        connector.setActive( true );
        Thread.sleep( Long.MAX_VALUE );
    }

    private static class DelayMessageHandler implements MessageHandler {
        public Map getSubscriptions() {
            Subscriptions subs = new Subscriptions();
            subs.addMType( "should.be.fast" );
            return subs;
        }
        public void receiveCall( HubConnection connection, String senderId,
                                 String msgId, Message msg )
                throws Exception {
            Response okResp = Response.createSuccessResponse( Response.EMPTY );
            connection.reply( msgId, okResp );
            doStuff();
        }
        public void receiveNotification( HubConnection connection,
                                         String senderId, Message msg )
                throws Exception {
            doStuff();
        }
        private void doStuff() throws InterruptedException {
            Thread.sleep( 5000 );
        }
    }
}