This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 36665 - QueueTool.waitEmpty is locked after a new window is opened
Summary: QueueTool.waitEmpty is locked after a new window is opened
Alias: None
Product: qa
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: PC Windows XP
: P1 blocker (vote)
Assignee: issues@qa
Depends on:
Reported: 2003-10-17 15:06 UTC by Jiri Skrivanek
Modified: 2011-02-17 09:32 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Test case to reproduce (923 bytes, text/plain)
2003-10-17 15:09 UTC, Jiri Skrivanek
Thread dump at the moment of waiting (10.65 KB, text/plain)
2003-10-17 15:10 UTC, Jiri Skrivanek

Note You need to log in before you can comment on or make changes to this bug.
Description Jiri Skrivanek 2003-10-17 15:06:45 UTC
When "new QueueTool().waitEmpty(500);" is called
after a file is opened by Open context menu, it is
somehow stuck and it fails when time expires. Try
attached test case in NetBeans dev IDE. It fails
only on *JDK1.4.2*. On JDK1.4.1 it works well. 
If you switch the focus from opened window to
another one, the lock is released and it passes.

From our previous discussion I am adding the
following observations:

If I modify test case to waitEmpty(5500); then:

on 1.4.1 - cursor stops blinking for 5500 ms when
QueueTool is waiting
on 1.4.2 - cursor is blinking all the time until
the window lose focus.
Comment 1 Jiri Skrivanek 2003-10-17 15:09:30 UTC
Created attachment 11896 [details]
Test case to reproduce
Comment 2 Jiri Skrivanek 2003-10-17 15:10:23 UTC
Created attachment 11897 [details]
Thread dump at the moment of waiting
Comment 3 Alexandre Iline 2003-10-21 05:06:55 UTC
What we see on 1.4.2 is right behavior - cursor should not stop all 
of the sudden because jemmy is waiting for the queue to be empty. :) 
This is an event fired by cursor blinking: 
on sun.awt.motif.MToolkit@10a5c37 
That event is posted both on 1.4.2 _and_ 1.4.1 (only if jemmy is not 
waiting for the queue to be empty). 
This last thing is wrong - coursor should've been blinkingon 1.4.1. 
And so, on 1.4.1 this test should be failing too. 
So, I do not consider this a bug. Closing the issue as invalid. If 
you want me to make it failing on 1.4.1, let me know. :| 
Right answer, most probably, would infolve different priorities for 
different event types. 
As for workaround, what we, clearly want here, is to ignore 
InvocationEvent, so, right approach would consist in using of 
EventTool class - it may be used for such stabilization. 
Comment 4 Jiri Skrivanek 2003-10-21 07:08:09 UTC
If "new QueueTool().waitEmpty(500);" has worked reliably on JDK1.4.1
then it should work the same way on JDK1.4.2. If it doesn't work, it
is regression in Jemmy for me. I don't know why is the difference
between 1.4.1 and 1.4.2 but to make it work we should filter
InvocationEvents from Timer, shoudn't we?
So, what are the possibilities:

1) Fix Jemmy to filter Timer events.
2) Recommend Jemmy users to not use QueueTool at all and use "new
EventTool().waitNoEvent(xxx);" instead

I would prefer 1).
Comment 5 Alexandre Iline 2003-10-21 08:32:14 UTC
Under "regression", we regularly mean that code was changed in a way 
that something, which was working before, is not working anymore. 
Code _was not_ changed, so we do not have a _regression_ here. 
Well, you may consider it a regression in java, since java code is 
what was changed, but I do not think you are talking about that. 
We may only talk about incompatibility. Well, that's true, obviously. 
And no, we should not filter timer event out. We had this discussions 
in the past, if you remember, the answer is no. 
The whole point on QueueTool class, is to realize that _nothing_ is 
happening to GUI. Timer events (and InvocationEvent in general),  
just like events of other types, can be used to update GUI.  
Problem with timer posts is mentioned several times in Jemmy doc,  
even though the doc is very old now. 
Back then, after the discussion, I created EventTool (it was created 
from Adam's code, if I recall it). This _is_ the tool if you want to 
check certain event types. And, BTW, remeber that no InvocationEvent 
can be caught by any AWTListener added by Toolkit.addAWTListener. 
Talking about this particular case, though, I would simply decrease 
time for the queue to be empty to some value to be less than  
cursor blinking rate. 
If you want to use EventTool after editor-opening operations, that is  
fine too. We are talking not about just any timer operation here, 
but about cursor blinking, right? 
Couple of facts for the closing: 
QueueTool _could not_ be rewritten to ignore one tipe of events - 
it would be EventTool. We may take it ofline, if you wish. 
I _have no idea_ how to create a workaround for 1.4.2, and I doubt it 
is possible. I suspect that difference is in event priorities, which 
we have not access to, from public API. 
Comment 6 Jiri Skrivanek 2003-10-21 14:00:14 UTC
OK, I will recommend to our users to not use QueueTool and use
EventTool istead, if they need something like that.
I agree to close this issue.
Comment 7 Jiri Skrivanek 2003-10-22 09:32:08 UTC
It is as designed, so nothing will be changed in Jemmy.
Comment 8 Jiri Skrivanek 2003-10-22 09:32:50 UTC