In my application, some process that is started in AWT's Event Dispatching Thread (EDT) may be interrupted under particular circumstances. Then it waits for input from the user. Alas, as the process is located in the EDT, the whole application freezes and the user is unable to relaunch the process, thus creating a deadlock. Is there any way to interrupt the EDT and lauch a new event pump from another thread ? Then the user would be able to interact with the UI.
What I am trying to do looks more or less like opening a modal dialog, except that I don't want a dialog because my component is complex. I'd rather display it right inside my root pane. So I had a look at how it's done in java.awt.Dialog, and had a pretty good understanding of it, but the most important classes that are used (EventDispatchThread, SequencedEvent, ...) are protected and therefore inaccessible for me.
Thank you all for your answers.
I'll be more specific. I am actually working on an application which embeds a homegrown scripting language. I am developing a debugger for this language. The debugger (as all debuggers) would stop the script execution whenever a breakpoint is met. The scripted processes can be triggered from many places (including from the EDT) in the code so taking the the process out of the EDT is not an option. I'd like the debugger UI to be embedded in the application (in a side pane to be precise). So when a breakpoint is met I would need the current thread (possibly the EDT, not to say mainly) to be interrupted and at least the debugger's UI should still be responsive. Also I am developing atop of the JDK 1.4 so no way to use JDK7 alas.
What I am currently doing is opening a JDialog with the debugger embedded. It all works fine but as I said I am not fully satisfied by this solution because I would really want my debugger to be embedded right in my main window.
If you are using JDK7, you can use the SecondaryLoop interface. An instance of this interface can be created through the EventQueue.createSecondaryLoop method
There was an informative blog post with an example but the server seems to be offline for the moment.
A small edit as I am still not fully sure I understand your question.
If you want to wait for user input from a worker thread, you can use the SwingUtilities.invokeAndWait method and use a blocking method (e.g. show a JOptionPane to retrieve user input). Due to the invokeAndWait your worker thread will be stopped until the Runnable on the EDT is processed. If you use a blocking method on the EDT to retrieve the user input that Runnable will only be finished when the user has provided his/her input
Related
When developing a Java GUI application (SWT or Swing based, should not matter), how to best profile the responsiveness, e.g. what consumes the time if the application feel sluggish on certain operations like clicking a button until something happens. The problem is in my understanding that the delays are quite low (usually < 0.5s) and hence hard to measure, because the most profilers I know you need to start and stop later.
The problem with profiling UI applications is that calls on the event dispatch thread (EDT) often originate from other threads or trigger background operations that eventually call something on the EDT. This can make it difficult to see the effects of a user action separately.
JProfiler has a feature called "Async tracking" that can track calls into the event dispatch threads of both AWT and SWT:
You have to profile with instrumentation and enable tracking:
Then you record CPU data and perform the actions that trigger actions on the EDT:
Finally, you click on "Inline async executions" to see the call tree across thread boundaries:
Disclaimer: My company develops JProfiler.
YourKit Java Profiler has built-in probe which automatically records all AWT/Swing events longer than 0.3 second, which can cause UI irresponsiveness:
https://www.yourkit.com/docs/java/help/awtevents.jsp
Disclaimer: I work for YourKit
Is it possible to create a multithreaded Java EE Glassfish container?
My intention is to create an application where users can capture data launch a social network, then each user would launch a new thread with the parameters he wants to retrieve information from the social network.
all these threads would be limited in number to avoid memory server.
As I can create multiple threads in java ee and that these once the user exits the application to remain running in the background until the user closes them?
One solution may be the job of glassfish?
Your question is pretty broad, but in general I understand you need to execute a thread for each user, which runs in background even when user stops using the application (logs out), does some repetitive task, and is terminated by user when required.
First, I would point out that this can be accomplished in cleaner way using timer service - you can schedule a periodical background job, which will do everyting you need. It can read the list of user and their tasks, perform them at a given interval. Then, a user may request to cance their tasks - they will remove their task from the list.
In this way, the number of users having the background task running would not be limited. They also can run sequentially in a single thread, but you may tweak that, see the rest of my answer.
More into on shceduling a timer in Java EE tutorial: https://docs.oracle.com/javaee/7/tutorial/ejb-basicexamples004.htm.
In case you really need a separate thread per user, there are several ways how to execute a thread separately from the request-handling thread. You might use asynchronous EJB method invocation, using #Asynchronous annotation. You may also inject ManagedExecutorService and use it to execute a Runnable asynchrnously using submit method. In both ways, you would not loose context and dependency injection will continue to work.
See more details about asynchronous eecution in Java EE tutorial about Concurrency utilities
You may also execute runnables asynchronously from a timer, but you may not need that, if you execute only a single task from within a timer handler, as timer handler will be executed when timer triggers in a new thread, if the previous handler did not complete yet.
Good Day to all:
My job is to create custom tools for our customers. My employer has a flagship product that we sell that has a Java interface. I then build tools (with Java) for our customers to make life easier for them. These tools run as plugins launched from within the Java interface.
My problem is that, during normal operation, I like to use SwingWorkers to do things. During debugging, I began to notice (with the NetBeans debugger) that even though a given SwingWorker was done, the thread was still running. Normally, this would not concern me, but I then began to notice that, even if the tool I was working on was closed, the Swing Worker was still hanging out in the pool. If I closed the primary application, of course all the threads would die as the JVM terminated, but if the primary app was still running, my SwingWorkers would hang around (even though the done & cancel flags are set).
Clearly this means that my Java app is using the primary applications EDT (which makes sense), but it leaves me with a problem. If I have a user who runs my tool multiple times during a single session with the primary app, then I'll start stacking up zombie SwingWorkers who aren't doing anything except chewing up a spot of memory & CPU.
So, the question I have for the hive mind, is there anyway to force terminate a zombie SwingWorker? Or, absent that, is there any way to re-attach to a Zombie SwingWorker if, for instance, I know it's name?
Thank you!
I think this is expected if you use a thread pool, which keeps threads hanging around (probably with an idle loop, causing them to show up as 'running').
The docs say that swingworkers can only execute once, so re-attaching them isn't possible. They aren't threads themselves, but executed on a worker thread.
You could limit the number of threads in the pool by using an ExecutorService.
See this SO question for more details.
We are experiencing a bug we cannot track down where something is freezing up our swing thread (it's been almost 2 weeks now and no real results) - we are experienced Swing programmers but we have a huge program and believe it to be in some of the legacy code
I am wondering, is there any way outside of editing the actual EventQueue class in the JDK which will allow us to view all pieces of our code currently running on the Event Dispatch Thread - maybe some type of tool which will allow us to view things as they enter or leave the event dispatch thread?
One interesting approach is to extend EventQueue and push() it, as shown here.
Logging everything that passes through the Event Dispatch Thread seems a cumbersome way to diagnose a freeze. Wouldn't it be easier to wait until the problem occurs, and then ask the Event Dispatch Thread what it's doing now? One way to do this is to enable JMX monitoring, connect to your running process with a JMX client such a VisualVM (which ships with the JDK), wait for the problem to occur, and then take a thread dump.
In case you still wish to log everything the Event Dispatch Thread is doing, you can do this by:
In Eclipse, launch the application in debug mode.
Create a breakpoint on EventQueue.dispatchEvent, right-click it, select "properties", check "condition", and enter the following "condition":
System.out.println(arg0);
return false;
It might be good idea to try BTrace to instrument the EventQueue and capture stack traces each time something gets added. I think the latest VisualVM has plugins that will allow you to instrument a running JVM with a BTrace script.
If you're using the Oracle JRE, there is a TracedEventQueue included already. You can install it as mentioned before:
EventQueue eventQueue = Toolkit.getDefaultToolkit().getSystemEventQueue();
eventQueue.push(new TracedEventQueue());
Note, this will output a lot of output...
I am writing a basic Java application with a Swing front-end. Basically it loads some data from a Derby database via Apache Cayenne and then displays it in a JTable. I'm doing my development in Eclipse and I don't think it's important but I'm using Maven for dependencies.
Now this works fine when I run using Debug but it seems to hang the display thread when I use the Run button. I've done a thread dump and I'm not 100% certain but everything looks good. I used Java VisualVM and the threads look fine there as well.
Strangely it seems to work intermittently. It's pretty consistent though and easy to reproduce. If anyone has any ideas, I'm all out of them.
It shouldn't be an issue that you are using Maven or Eclipse for Swing apps. We do that all that time with no problems. You said you're not 100% that everything looks good with the threads, so a posting of your threads would be useful, particularly when your application is hung - it's possible you have a deadlock.
The fact that you say it happens intermittently leads me to believe it's a threading problem. The debugger running may cause the threads to run differently, which is why it might work in debug mode. Swing threading issues are frequently caused by not performing GUI updates on the event dispatch thread since Swing is not threadsafe. Any operation that updates a swing component directly or indirectly (meaning if it updates the table model, which then updates the table) must be done on the event dispatch thread
If you can narrow down the block of code that is being invoked when the application freezes, you should post that if you can, and that would be helpful as well.