Archived

This forum has been archived. Please start a new discussion on GitHub.

Thread/Async/Dispatcher consideration in Java Swing GUI

Some question about Thread/Async/Dispatcher writing Ice applications of Java Swing GUI.

1. As an Ice client who invoke messages onto servers and then wait for responses, using twoway calls, Which approach (1.1/1.2) is better:

1.1 As the recommended way in Swing tutorials, for possible long running tasks, from the event-triggered (e.g. button clicked), spawn a new thread to make a simple synchronous invocation . When waiting for the server, only this new thread is blocked (Is 1 Ice client thread also occupied?). When the response comes back, process in this same new thread, update result with the Swing Event Dispatcher thread by using javax.swing.SwingUtilities.invokeLater()

1.2 As in "http://doc.zeroc.com/display/Ice/Dispatching+Invocations+to+User+Threads", in the event-triggered (e.g. button clicked) Event dispatch thread, issue an AMI call (normally a quick action), and setting up Ice dispatcher so that response is directed from the Ice core to the Event Dispatch Thread, process and update UI


2. Any different if not just plain Java Swing but also the NetBeans platform is used?



3. What about an IceStorm Subscriber? As a subscriber create an adaptor and wait for messages from IceStorm, I see it as a server, and so dispatcher MUST be setup to let Ice invocation to be run in GUI event dispatch thread to udpate GUI components, is that true?


Thanks!