How to deprioritize Java testrunner in Eclipse breakpoints?

Question

If I am debugging some multithreaded Java code in Eclipse - with a main class RunTest, and an interesting class QueueListener.

Assumptions:

When RunTest is initialized - QueueListener runs in the background.
When RunTest finalises - QueueListener is terminated
There is a single method in RunTest - with a breakpoint in it
There is a single method in QueueListener with a breakpoint in it
QueueListener can run over and over again
RunTest only runs once per execution (parent class)

When debugging in Eclipse - both breakpoints come up. But Eclipse gives priority to RunTest - and I have to manually flip it over to the QueueListener by selecting that thread in the debugger - and keep repeating this over and over.

Is there a way to tell Eclipse that I'm more interested in the QueueListener, and consider the testrunner to be a lower priority - when it chooses debug breakpoints to show?

Can I know the name of the Application, for which you are debugging? Is RunTest called the driverscript in the AutomationFramework ? — Harshavardhan Konakanchi, Mar 28 '13 at 12:48

Joe Elleson · Accepted Answer · 2013-03-28T13:47:56.957

The answer can be found in the eclipse source code within the ThreadEventHandler method. There is a queue of suspended threads, as below:

/**
 * Queue of suspended threads to choose from when needing
 * to select a thread when another is resumed. Threads
 * are added in the order they suspend.
 */
private Set fThreadQueue = new LinkedHashSet();

Further down, every time a breakpoint is hit, the suspended thread is added to this queue:

protected void handleSuspend(DebugEvent event) {
   ...
   queueSuspendedThread(event);
   ...
}

The method to get the next suspended thread is:

protected synchronized IThread getNextSuspendedThread() {
    if (!fThreadQueue.isEmpty()) {
        return (IThread) fThreadQueue.iterator().next();
    }
    return null;
}

So the answer is no, there is no control over the order, it will strictly be in the order that each thread hits the breakpoint and is added to the underlying queue.

In practice, this actually means that once your RunTest thread is at the head of the queue, it will remain there until you resume it, so by resuming each of the QueueListener after this point it will ALWAYS revert to your RunTest thread — Joe Elleson, Mar 28 '13 at 14:36
So it's just FIFO - fair enough. Thanks for the well researched answer. — hawkeye, Mar 28 '13 at 20:35

score 0 · Answer 2 · answered Mar 28 '13 at 13:27

There is no priority involved, but this just depends on the timing behavior of your application. Probably your 2 breakpoints are hit in a very short amount of time, but always in the same order. And then eclipse will always open the editor (and scroll to the thread) of only one of them (where I don't exactly know the chosen strategy, but I would guess the first breakpoint that occured).

You don't really want to have your editors/views changed all the time when debugging a multithreaded application and hitting breakpoints every some seconds, or do you?

How to deprioritize Java testrunner in Eclipse breakpoints?

2 Answers2

Linked