swing and spring integration – threading - part4

Typically, GUI applications have the issue that the UI itself runs in its own thread and  follows some type of event-driven design. Multi-threaded GUI’s are hard to write. The event dispatching model will typically have a way to run tasks on its  thread that works with (versus against) the UI system. In swing, the EDT is the event-dispatch-thread and performs this function for java swing.

If we are running a system that is suppose to handle publishing and consuming by handlers that are typically tied to the EDT, how do we arrange for all of the channel activities to be on the right thread?

One way, not so safe, is to ensure that the channel and entire infrastructure is created an runs on the EDT. We can do this by wrapping the entire program in a SwingUtilities.invokeLater(…) method to launch the program. If you look at the demo code, this is what we do. So we seem safe, at least, until we are publishing and consuming in a side thread because of a long running task or some other scenario that allows messages to be injected into our channels from outside the EDT. This leads to the second approach.

The second approach is to ensure that an message dispatching occurring inside the channel occurs on the EDT. If a subscribing message handler has a long running task it needs to run, it can cerate one using normal threading and integration techniquies e.g. see here. However, regardless of the thread where a published message is created, we want to ensure it runs on the EDT. To do this, we simply need to add an executor to the main publish and subscribe channel. The spring integration namespace config provides a task-executor attribute to attach an executor to use for dispatching events. What do we use for this attribute? We can create a very simple SwingExecutor. Lets assume that you want the swing executor to invoke its dispatch using “invoke later” to avoid a potential deadlock under invoke-and-wait. Because it uses invoke-later, you’ll need to be cognizant of timing issues related to the running of the dispatch to a handler and any sequenced updates/changes that are important to your code.

The code for the executor is:

And the configuration is:

Comments

Post a Comment

Popular posts from this blog

quick note on scala.js, react hooks, monix, auth

quick note on scala.js, react hooks, monix, auth Reactjs hooks finally came out of preview in a recent version of React. scalajs-reaction has had support for hooks since they were in preview. React hooks seem like the hot new thing but for me the question is, do hooks help improve your code by improving maintainability, time to market, TCO, etc.? Let’s take a look using authentication as an example and employ monix , a reactive observable framework that also builds on cats . We will assume we are building a SPA. Does it improve your code and make your application & development experience better? Auth Auth processing can be complex. Many react auth examples you find in blogs like to show how to use “react-routing” and “auth” as a switch that determines which routes are protected or unprotected. Protected routes show application specific data. Unprotected routes show login content . Based on storing a “User” object in the browser session/local storage, th
Read more

zio environment and modules pattern: zio, scala.js, react, query management

zio environment and modules pattern: zio, scala.js, react, query management This blog covers a zio-based fetch design for scala.js, react web applications. It heavily uses the zio “environment” feature to help motivate a point of view on the modules pattern in effect systems. At the end, I summarize some thoughts on ergonomics and complexity. This blog assumes a basic knowledge of zio and react. scala.js is just like scala so you mostly already know scala.js. This blog is a follow-on to previous blogs: https://appddeevvmeanderings.blogspot.com/2019/10/scalajs-react-fetcher-hook_48.html and https://appddeevvmeanderings.blogspot.com/2019/11/scalajs-and-react-suspense.html . I have been keeping an eye on and culling ideas from typscript/javascript fetching libraries that address query management concerns. The formulation below incorporates some of those concerns but does not try to comprehensively duplicate well established javascript libraries. I only care about
Read more

user experience, scala.js, cats-effect, IO

user experience, scala.js, cats-effect, IO This is not a complicated snippet but I wanted to ensure I remembered it. When creating a UI, say react for browsers, you will run into the “fetch” data problem. When you fetch data, you typically have a component that performs the fetch and acts as a cache for the result. The fetch component renders a child and passes along the data that was fetched (or the fetch state, etc.). Even with the upcoming react suspense mechanism that will make this a smoother user experience, you may have a flash of a “loading” indicator that shows for a moment before the content is fetched from the server. If the flash is too fast, it is visually disruptive. A shimmer mechanism for the UI my also not be the answer. Similarly, if the fetch request takes too long, you will want it to time-out and show an error message that the data could not be fetched or whatever is appropriate for feedback in your application. Generally, I use cats-effect
Read more