You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2012/05/13 11:00:05 UTC
[Bug 53226] New: [Patch] faster startup
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Priority: P2
Bug ID: 53226
Assignee: issues@jmeter.apache.org
Summary: [Patch] faster startup
Severity: enhancement
Classification: Unclassified
OS: All
Reporter: immanuel.hayden@gmail.com
Hardware: All
Status: NEW
Version: Nightly (Please specify date)
Component: Main
Product: JMeter
Created attachment 28766
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28766&action=edit
Adding cache and more intelligent filtering to facilitate faster startup
Hi!
As I am really pissed by the relatively slow startup of jmeter, I looked into
what could be done to enhance the situation. The patch modifies the following
two files:
- core/org/apache/jmeter/gui/action/ActionRouter.java -> filter by
"org.apache.jmeter.gui" through the inbuilt functionality of
"findClassesThatExtend", as it stops a ton of ClassFinder.isChildOf (sloooooow)
calls.
- jorphan/org/apache/jorphan/reflect/ClassFinder.java -> add a cache for jars
(containing jar -> classes in jar) and a cache for classes loaded through
Class.forName (you should think class.forname has that builtin, but if I remove
it I also lose performance). Previously we repeatedly walked the same folder
again when loading jars in different parts of the startup process -> with the
cache we walk each distinct file only once (discerned by canonical path). Also
the "addJarsInPath" had some really strange quirks which I fixed (regarding
dirs that end with ".jar" and also I think more than one level of subdirs would
not have worked).
All Performance analysis courtesy of Netbeans ;)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #14 from immanuel.hayden@gmail.com ---
Also if you implement the cache strictly as a cache and not as the sole source
of serving the information then it should be no problem either way. If you add
new paths it just results in cache-misses (as the jar files found in the new
paths are not in the cache yet) and would be loaded by the failover and added
to the cache.
(In reply to comment #13)
> (In reply to comment #11)
> ...
> > Also, in GUI mode the classpath can be updated at run-time using the Test
> > Plan "Library" entries.
>
> The Library entries are used to update the run-time classloader only, and do
> not change the classpath.
>
> AFAICT this means that the ClassFinder will not be affected by any library
> entries.
>
> ...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #17 from Sebb <se...@apache.org> ---
(In reply to comment #16)
> (In reply to comment #15)
> > As far as I can tell, most of the work has to happen anyway; there is now
> > very little duplication of effort.
> >
> > So what benefit would a cache provide?
>
> Well, we call "findClassesThatExtend" with the same path(s)[1] multiple
> times, which in turn calls "addJarsInPath" which searches through the FS and
> "findClassesInPaths" which opens and searches the found Jar-Files for
> classes. So if we can eliminate doing that whole stuff multiple times, we
> should see a performance gain, esp. on machines with slow disks like the one
> at my workplace (albeit I am not sure how much OS-level FS-caching would
> play a role).
Yes, that might make sense; and the amount of memory required to cache the
result is relatively small - always shorter than the classpath.
> However, caching the Classes as I also proposed does not make sense, as my
> current research indicates that Class.forName() has a cache in itself.
Also, the cache would be a lot larger.
>
> [1] normally it's "JMeterUtils.getSearchPaths()", except for two cases or so
> where we have a hardcoded path.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[Patch] faster startup |Faster startup
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #19 from Sebb <se...@apache.org> ---
(In reply to comment #18)
> On a related note: is there a way for gui-components to get a notification
> when they are first rendered? I poked around in the Event-Tree but I'm not
> really getting the hang of it :(
Please ask such questions on the JMeter dev list.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #20 from Sebb <se...@apache.org> ---
(In reply to comment #18)
> Created attachment 28832 [details]
> Adds a path -> classes cache to the ClassFinder
>
> Added a cache to the ClassFinder (tried to get it done with minimal
> destruction) to cache all found classes in the paths. Cannot really say if
> it makes much difference as I have a bunch of other changes too which affect
> the performance, but at least I didn't spot any regressions when quickly
> checking the menus.
The cache uses HashMap which is not thread-safe.
It also looks as though it could use a lot of memory.
Caching is nearly always a trade-off between speed and memory; without any
evidence of a speed improvement it's impossible to justify the change.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Milamber <mi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #28766|0 |1
is obsolete| |
--- Comment #2 from Milamber <mi...@apache.org> ---
Created attachment 28767
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28767&action=edit
Some changes on code style
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #11 from Sebb <se...@apache.org> ---
Adding caching to the classfinder might be possible, but would need to be
carefully done so as not to impact non-GUI mode.
Also, in GUI mode the classpath can be updated at run-time using the Test Plan
"Library" entries.
A cache will take additional memory.
Any time savings produced by a cache needs to be carefully balanced against the
additional processing and memory requirements.
However, fixes such the one for ActionRouter are obviously worthwhile.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #8 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Integrated ActionRouter part of patch
Date: Sun May 13 20:10:41 2012
New Revision: 1337977
URL: http://svn.apache.org/viewvc?rev=1337977&view=rev
Log:
Bug 53226 - Faster startup
Filter during search
Modified:
jmeter/trunk/src/core/org/apache/jmeter/gui/action/ActionRouter.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #3 from immanuel.hayden@gmail.com ---
k, will check it out in the afternoon (currently I'm not capable of thinking
after a good lunch ;))
7 to 3 seconds sounds really promising (my home machine is too fast and has an
ssd -> from 1.3 to 0.7 is my current improvement, but I'm doing this for the
bad performance of my machine at work), good that the improvements are not only
noticeable by me :)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #9 from immanuel.hayden@gmail.com ---
> Integrated ActionRouter part of patch
you also need to make that interface public, currently it's private for unknown
reasons (which is strange as all function calls to it parse hardcoded null as
include- and exclude-params -> totally useless).
> Looking at code, I don't understand why you Override addAll in
> FilterTreeSet, can you explain ?
I tried without the override but it didn't work, maybe the parent.addAll does
something differently than just calling add() (where we do the filtering) in a
loop.
> I may have missed something but I also think your patch does not handle
> fully what was in findClassesInPathsDir, this part:
maybe I misunderstood the whole complex of "findClassesInPaths" ... but to me
it seemed the intention was to load all jars and classes that are in the tree
and all subdirectories. However, after looking at the code again, it parses a
structure like this: Jars only in the top folder(s), class files in arbitrary
deep subfolders (which imo is strange).
My code currently only loads jar-files (as we only have jar-files), but with
another if in the line 191 (patched version) we could also include class-files
just as easily.
Anyhow, I think I will check (just check) why plugins are loaded "the stupid
way" (have 10 different places call the ClassFinder, searching all jars,
instead of just having some static registerPlugin() method in the class which
does the hooking just once) and if it can be done faster ... Eg. it could work
something like this: ClassFinder loads plugins, while the main thread
initializes the gui (in parallel) -> once they are done the ClassFinder
populates the menus and so on by calling the registerPlugin of the loaded jars
and classes ... but I'm way ahead of myself (and my rusty coding skills) there
;)
Maybe someone should cick off a GSOC-Project for this next year ;)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
immanuel.hayden@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #28766|0 |1
is patch| |
Attachment #28766|application/octet-stream |text/plain
mime type| |
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p.mouawad@ubik-ingenierie.c
| |om
--- Comment #7 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Hello Immanuel,
Looking at code, I don't understand why you Override addAll in FilterTreeSet,
can you explain ?
I may have missed something but I also think your patch does not handle fully
what was in findClassesInPathsDir, this part:
"else if (list[i].endsWith(DOT_CLASS) && file.exists() && (file.length() != 0))
{
final String path = file.getPath();
listClasses.add(path.substring(strPathElement.length() + 1,
path.lastIndexOf(".")) // $NON-NLS-1$
.replace(File.separator.charAt(0), '.')); //
$NON-NLS-1$
}"
Did you find this code was not useful ?
Thanks
Regards
Philippe
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #10 from Sebb <se...@apache.org> ---
URL: http://svn.apache.org/viewvc?rev=1338465&view=rev
Log:
Bug 53226 - Faster startup
No need to check for abstract classes, as these are eliminated by the class
finder
Modified:
jmeter/trunk/src/core/org/apache/jmeter/gui/action/ActionRouter.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
immanuel.hayden@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #28768|0 |1
is obsolete| |
--- Comment #18 from immanuel.hayden@gmail.com ---
Created attachment 28832
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28832&action=edit
Adds a path -> classes cache to the ClassFinder
Added a cache to the ClassFinder (tried to get it done with minimal
destruction) to cache all found classes in the paths. Cannot really say if it
makes much difference as I have a bunch of other changes too which affect the
performance, but at least I didn't spot any regressions when quickly checking
the menus.
On a related note: is there a way for gui-components to get a notification when
they are first rendered? I poked around in the Event-Tree but I'm not really
getting the hang of it :(
Reason: We initilize every gui-component with all it's components, panels and
so on, just to populate the menu. I understand that this is needed because you
can't do abstract static methods in java, but some take exceedingly long to
initialize all their stuff eventhough they are most probably never used by the
user.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #12 from Sebb <se...@apache.org> ---
Avoid duplicate Function lookup.
URL: http://svn.apache.org/viewvc?rev=1338954&view=rev
Log:
Bug 53226 - Faster startup
FunctionHelper can use function list created by CompoundVariable
Modified:
jmeter/trunk/src/core/org/apache/jmeter/engine/util/CompoundVariable.java
jmeter/trunk/src/core/org/apache/jmeter/functions/gui/FunctionHelper.java
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #16 from immanuel.hayden@gmail.com ---
(In reply to comment #15)
> As far as I can tell, most of the work has to happen anyway; there is now
> very little duplication of effort.
>
> So what benefit would a cache provide?
Well, we call "findClassesThatExtend" with the same path(s)[1] multiple times,
which in turn calls "addJarsInPath" which searches through the FS and
"findClassesInPaths" which opens and searches the found Jar-Files for classes.
So if we can eliminate doing that whole stuff multiple times, we should see a
performance gain, esp. on machines with slow disks like the one at my workplace
(albeit I am not sure how much OS-level FS-caching would play a role).
However, caching the Classes as I also proposed does not make sense, as my
current research indicates that Class.forName() has a cache in itself.
[1] normally it's "JMeterUtils.getSearchPaths()", except for two cases or so
where we have a hardcoded path.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #6 from immanuel.hayden@gmail.com ---
damn :/
I think I get the problem just now: Sooner or later all classes that we load
from the jars get initialized in the "isChildOf" (called 5958 times in total
during starup) which is the point where we ultimately filter the classes for
the "findClassesThatExtend" methods. As long as we always execute that method
for all classes, we are pretty much screwed.
- The jarCache should still make sense though, as you get around doing all the
Zip-File handling repeatedly. But maybe the JarInputStream is slower than using
ZipFile/JarFile class and reading the all entries at once.
- Pre-loading in a 2nd thread would maybe make sense, but you would have to
kick it off at the beginning of the "JMeter.startGui" method, as that is the
only point in the chain that we take noticeable self-time instead of falling
through. This is only feasible if the JMeterUtils.getSearchPath() is defined
there already (as it is the 99%-case for search path that I could find in the
code).
Another really show thing that shows up (though in the awt-, and not the
main-thread) is the MenuFactory.initializeMenus() function, which creates
instances of quite some classes to fill the menu ... esp. as some classes like
SmtpSamplerGui take 160ms for that, which is 1/6 of the threads cpu-time (2nd
worst is TestBeanGUI which takes 120, all others luckily take less than 30ms,
down to 0.0... ms). I think I will also check this out when I have time, could
be that this is also holding back the main-thread in some way.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |FIXED
--- Comment #21 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
I close this one as some improvements have been done.
Going further might introduce regressions.
On my computer (3 years old Mac OSX), JMeter starts in 3s.
Reopen if you find more enhancements.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #13 from Sebb <se...@apache.org> ---
(In reply to comment #11)
...
> Also, in GUI mode the classpath can be updated at run-time using the Test
> Plan "Library" entries.
The Library entries are used to update the run-time classloader only, and do
not change the classpath.
AFAICT this means that the ClassFinder will not be affected by any library
entries.
...
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
immanuel.hayden@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
immanuel.hayden@gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #28767|0 |1
is obsolete| |
--- Comment #4 from immanuel.hayden@gmail.com ---
Created attachment 28768
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28768&action=edit
regression fix for Milamber :)
ah, couldn't leave my fingers off it. the problem was bad thinking in the
addJarsToCache-method: I intended to return all traversed jars, but only
returned the ones I newly added to the cache. now you should be able to open
test plans again and also see elements in Edit->Add->[All Submenus]. I think
this was the last sequence I wrote yesterday night (somewhen around 2am) so
that's probably the reason I didn't check so thoroughly any more ;)
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Milamber <mi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #5 from Milamber <mi...@apache.org> ---
With the new patch revision, the start time isn't faster.
Stats:
* Current trunk: 2524 ms
* First patch version (JMeter's menu not work): 876 ms
* Patch rev1: 2737 ms
to get stat:
add this line in jmeter.properties (or user.properties)
log_format=%{time} %5.5{priority} - %{category}: %{message} %{throwable}
And make some calculation.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] Faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
--- Comment #15 from Sebb <se...@apache.org> ---
As far as I can tell, most of the work has to happen anyway; there is now very
little duplication of effort.
So what benefit would a cache provide?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 53226] [Patch] faster startup
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=53226
Milamber <mi...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #1 from Milamber <mi...@apache.org> ---
Thanks for your submission.
Start-up time is better (in my computer : 7sec -> 3 sec), but a regression was
introduce.
When I open a jmeter jmx file which contains a View results tree, I have some
errors:
2012/05/13 09:41:57 ERROR - jmeter.gui.GuiPackage: Problem retrieving gui
java.lang.NullPointerException
at
org.apache.jmeter.visualizers.ViewResultsFullVisualizer.init(ViewResultsFullVisualizer.java:223)
at
org.apache.jmeter.visualizers.ViewResultsFullVisualizer.<init>(ViewResultsFullVisualizer.java:121)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.apache.jmeter.gui.GuiPackage.getGuiFromCache(GuiPackage.java:381)
at org.apache.jmeter.gui.GuiPackage.getGui(GuiPackage.java:219)
at org.apache.jmeter.gui.GuiPackage.getGui(GuiPackage.java:190)
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addComponent(JMeterTreeModel.java:127)
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addSubTree(JMeterTreeModel.java:112)
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addSubTree(JMeterTreeModel.java:104)
at org.apache.jmeter.gui.GuiPackage.addSubTree(GuiPackage.java:471)
at org.apache.jmeter.gui.action.Load.insertLoadedTree(Load.java:178)
at org.apache.jmeter.gui.action.Load.loadProjectFile(Load.java:111)
at
org.apache.jmeter.gui.action.LoadRecentProject.doAction(LoadRecentProject.java:68)
at
org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:80)
at
org.apache.jmeter.gui.action.ActionRouter.access$000(ActionRouter.java:41)
at org.apache.jmeter.gui.action.ActionRouter$1.run(ActionRouter.java:62)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
2012/05/13 09:41:57 WARN - jmeter.gui.action.Load: Unexpected error
java.lang.NullPointerException
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addComponent(JMeterTreeModel.java:128)
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addSubTree(JMeterTreeModel.java:112)
at
org.apache.jmeter.gui.tree.JMeterTreeModel.addSubTree(JMeterTreeModel.java:104)
at org.apache.jmeter.gui.GuiPackage.addSubTree(GuiPackage.java:471)
at org.apache.jmeter.gui.action.Load.insertLoadedTree(Load.java:178)
at org.apache.jmeter.gui.action.Load.loadProjectFile(Load.java:111)
at
org.apache.jmeter.gui.action.LoadRecentProject.doAction(LoadRecentProject.java:68)
at
org.apache.jmeter.gui.action.ActionRouter.performAction(ActionRouter.java:80)
at
org.apache.jmeter.gui.action.ActionRouter.access$000(ActionRouter.java:41)
at org.apache.jmeter.gui.action.ActionRouter$1.run(ActionRouter.java:62)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
--
You are receiving this mail because:
You are the assignee for the bug.