JSAMP HUB waits for callee before returning to caller

[Mark Taylor]

On Wed, 2 Jul 2014, Laurent Bourgès wrote:

> Mark,
> 
> I tested today the JSAMP async variant concerning shutdown issues I spotted
> two years ago.
> 
> 
> 1/ It takes me some time to update my test classes (+ shells) related to
> both client & hub shutdown.
> 
> For me, everything is fine: no ghost or leaking client / hub encountered.

great.

> Just surprised by the connection listener that is not called during
> shutdown, but it seems normal:
> - HubConnection.unregister() called => hub
> - GuiConnector (GUI wrapper on low-level hub connection) not notified => no
> listener called

Does this mean that some clients fail to unregister when the
JVM hosting them is shut down?

> I enabled the java console tracing to get javaws exceptions and there is
> still one related to WebHubProfile.stop():
> 
> 14:26:21.650 INFO  [AWT-EventQueue-2] fr.jmmc - Exiting with status code
> '0'.
> WARNING: Shutdown hook failure: java.lang.IllegalStateException: zip file
> closed
> java.lang.IllegalStateException: zip file closed
...
> 
> To fix it, I modified this class to preload the Runnable class invoked in
> the stop() method.

I have incorporated basically this fix with some stylistic alterations -
commit 0408cb8 on branch async-call.  Can you confirm that this works
properly for you?

> Finally all my tests are OK and I provide a minor patch to avoid any
> exception thrown in JNLP environment:
> Good job, mark !

Good job Laurent!  thanks a lot for the tests, I feel fairly confident
that it's OK now, I know that you're thorough!

> PS: I think the documentation related to multi-threading in the SAMP
> protocol & implementations could be improved as there is two API levels:
> - low-level: creates one SAMP threads per message and can lead to
> concurrency issues (take care)
> - GUI level (Java): using the Event Dispatcher Thread (single thread)
> ensures Swing components are consistent and thread-safe
> 
> But in JSamp, there is so many features (hub, profiles, connections) that
> it is not always obvious which threading model is in use (low-level or GUI)
> ie single (thread-safe) / multiple threads and if it is a blocking / non
> blocking behaviour.

Fair comment - in my defense I'm following the practice of the J2SE
which generally assumes that you know which methods have to be called
on the EDT rather than actually telling you about it.
The rules (I think) are similar here: things that have to do with Swing
ought to be called on the EDT.  But if I get a load of free time I'll
consider adding some text (or even @Annotations) to make this explicit.

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/