console writer thread causes erratic event handling

[amullick]

I have a swing applet in jdk 1.4 that has a number of focus listeners.
After tracing I've discovered that most of the events are being
assigned to the event queue thread of the applet thread group. However,
some events are also being assigned to the plugin thread group which
contains the console writer thread and its own event queue thread. The
event thread in the plugin thread group runs at a higher priority which
interrupts the event thread in the applet thread group. If the
interrupting and the interrupted methods belong to the same class
depending upon timing, some class objects can get overlaid leading to
unpredictable results. One such result is two blinking carets in two
separate fields at the same time. In addition, the higher priority
thread handles events out of turn. Once the events assigned to the
higher priority thread are exhausted, the event handling by the applet
event thread resumes, and such older events are being handled later.
Out of sequence event handling also carries unpredictable results. For
example a focus gain method might be looking at a component that no
longer has focus.

As a test, when I checked the option to not start the console, the
above symptoms disappeared. The console writer thread was introduced by
Sun as a performance improvement so as not to block println output to
the console. I would like the console to be present because it is being
used for viewing tracing output generated by the applet. This reminds
me of the Uncertainty Principle which says if you look at it, it
changes its behavior. The fact that the jvm schedules event handling in
two separate event threads, looks like a bug. In the meantime, I have
to fix this somehow. Does someone know how to disable the plugin thread
group (containing the console writer thread) without disabling the
console?

Anup

 

[Roedy Green]

I have a swing applet in jdk 1.4 that has a number of focus listeners.

I have suggested a number of things to track down why your events are
getting on the wrong thread. I don't know if you have tried them.

If you don't want to do that, you are going to have to create yourself
a tool to dump the event queues and perhaps from that figure out what
you are doing wrong.

 

[amullick]

Roedy, I have done the things you have suggested. For every event
handler, I have traced the current thread name, the priority, the group
thread name and all the threads in the group. I have also traced the
same info in mainline as well as the first method to receive control as
a result of invokeLater. I'm not purposely running under the console
writer thread. I'd have to go out of my way to have the mainline run
under this thread. I did notice on some occasions the event handlers
run under the Plugin group event thread. I suspect that's because the
jvm assigned them possibly due to an overload on the applet event
thread. My suspicion is based on the fact that most of the time the
event handlers are running on the applet event thread. Then I see a
bunch of them running under plugin event thread. When these are
depleted, I see them running again under the applet event thread.

Anup