Monday, July 05, 2004

Swing, Threading, and Application Architectures Here's an interesting thread on writing efficient swing code (http://www.javalobby.org/thread.jspa?forumID=61&;threadID=13166). It's interesting to me because it talks about improving swing perfomance by not doing work in the UI thread. I would say this is obvious, but i've noticed in general threads are not talked about much in java. As threads are built into java you might expect a more energetic discussion. But unfortunately threads in java make it so easy to screw things up. The UI by at least not defaulting to having work done in another thread has caused Swing years and years of bad press. Observers not requiring notifications to be processed in a separate thread, for example, is a disaster waiting to happen. In the naive implementation of java you can handle notifications sagely by proving a bridge to an Actor type architecture, but few people know or will think to do it. Instead you get tangles of recursive code with entirely unpredictable latencies and deadlock characteristics. High performance applications consider threading architectures very carefully, as they do in SEDA (http://www.eecs.harvard.edu/~mdw/proj/seda/), for example. These issues are not related to swing only, they exist in every application, every jvm, every system. Inputs like databases, tcp/ip, rmi, soap, jms, servlets, etc all have the same problems of dispatching work, getting work done, and dealing with notifications from all the work performed which inturn causes more work, more notifications, etc. Container frameworks like Spring generally assume work is processed in a single thread. Thread local variables are used to transparently store transaction information or AOP is used to declaratively support transactions. This approach doesn't support moving work to different threads for different processing steps. Nor does it allow you to condition your total work load by limiting CPU usage, aggregating requests, using task priorities, using work priorities, using back pressure, etc. In fact, threads are rarely mentioned at all. It seems the servlet or something allocates a thread and that's it. Many developers i talk to have no idea what thread there code is running in at any given time. When people talk about scaling they only talk about upping the number of threads in a thread pool. They don't talk about priorities, deadlock, queuing, latencies, and a lot of other issues to consider when structuring applications. For example, on an incomming request from a browser you want to setup the tcp/ip connection immediately so that the browser doesn't have to retry. Retries add load and make the user experience horrible. Instead what you would like to do is set up the connection, then queue up the request and satisfy it later after having immediately setup the connection. But if each request is handled by a single thread then you can't implement this sort of architecture and your responsiveness will appear horrible as you run out of threads or threads run slow, or threads block other threads on locks, when in fact you have tons of CPU resources available. Based on the source of the request you could assign the work specific priority or drop it immediately. You can also do things like priorities different phases of a process. If one phase hits the disk you know that takes a lot of time relative to other in memory operations. As your application scales you decide if that phase of the work is more important and give it a higher priority or you can possible drop work elsewhere because you don't want to a request to fail once it has reached a certain processing point. Consider if an object queued to it a UI request, servlet work, and database work. The work could be organized by priority. Maybe you want to handle the UI work first so it queues ahead. But if you keep getting UI work it will starve the other clients so you give other clients a chance to process work. And so on. I think java might get less bad press if java provided a more structured model of architecting systems using threads. For a general architecture discussion take a look at http://www.possibility.com/epowiki/Wiki.jsp?page=ArchitectureDiscussion. For my general solution discussion take a look at http://www.possibility.com/epowiki/Wiki.jsp?page=AppBackplane. comment[] 11:04:25 AM

© Copyright 2006 todd hoff. Last update: 7/11/2006; 1:01:09 PM.