Board index » jbuilder » Gui goes unstable

Gui goes unstable


2004-01-28 02:01:42 AM
jbuilder7
Hi,
We have a gui with half a dozen frames using JdbTables, JdbNavComboBoxes,
QueryDataSets and so on. Only one instance of each frame & query data set
is created (but the qds are refreshed in some of the frames). I can cycle
through the frames about 6 times. The first 4 times are fine. On the fifth
time the app seems to be slowing down. On the sixth time the app gets to
the point where I merely have to click on e.g. the down arrow at the right
of a JdbNavComboBox and the app seems to go into some sort of race
condition. The garbage collector shows that there is maybe 40Mb free on the
heap before I do the above click. The garbage collector starts immense
activity and shows that all the memory on the heap is being rapidly consumed
and the CPU is at 100%. Sometimes it may settle down after several seconds
and stop and sometimes it just runs out of heap and I get an out of memory
error. If it settles down then will invariable die on the next Swing event
i.e. if I click the ComboBox down arrow again.
The effect is similar to the race condition that happens when you fire an
event that then fires itself. I'm having trouble with this one. I don't
believe I am firing an event that fires itself because that invariably
causes the app to die as soon as it happens. Has anyone come across this
before, have any ideas about what might be happening or how I could approach
tracking it down?
On my machine the failure is absolutely consistent, I go through the same
set of actions and it will always fail after about 6 cycles. The precise
frame it fails on does vary.
Thanks
Simon
 
 

Re:Gui goes unstable

Simon Bisson wrote:
Quote
Hi,

We have a gui with half a dozen frames using JdbTables, JdbNavComboBoxes,
QueryDataSets and so on. Only one instance of each frame & query data set
is created (but the qds are refreshed in some of the frames). I can cycle
through the frames about 6 times. The first 4 times are fine. On the
fifth
time the app seems to be slowing down. On the sixth time the app gets to
the point where I merely have to click on e.g. the down arrow at the right
of a JdbNavComboBox and the app seems to go into some sort of race
condition. The garbage collector shows that there is maybe 40Mb free on
the
heap before I do the above click. The garbage collector starts immense
activity and shows that all the memory on the heap is being rapidly
consumed
and the CPU is at 100%. Sometimes it may settle down after several
seconds and stop and sometimes it just runs out of heap and I get an out
of memory
error. If it settles down then will invariable die on the next Swing
event i.e. if I click the ComboBox down arrow again.

The effect is similar to the race condition that happens when you fire an
event that then fires itself. I'm having trouble with this one. I don't
believe I am firing an event that fires itself because that invariably
causes the app to die as soon as it happens. Has anyone come across this
before, have any ideas about what might be happening or how I could
approach tracking it down?

On my machine the failure is absolutely consistent, I go through the same
set of actions and it will always fail after about 6 cycles. The precise
frame it fails on does vary.

Thanks

Simon
Without more information, it is a stab in the dark, but I would look at the
following:
First, run the application, from a command line using java -verbose and
check the stack trace. I do not know for sure, of course, but I would guess
that you are either:
(1) Failing to dispose of the frames and creating new instances while the
others are still loaded. This could be due to static methods, or something
that does not cause the GUI to go out of scope (like a centralized JMenu or
Menu Actions).
(2) You are using static methods in your DataModules, but creating new
instances, which would mean that you are creating repetitive classes and/or
connections and queries without freeing former instances.
(3) You are creating multiple connections to the database by using Database
connections for each and every data module, instead of some type of pooling
mechanusm (see above for why this could occur). By default, the DataModules
will create a new Database connection for each and every DataModile and tie
the QueryDataSets to that Database. Every time you create a shared instance
of the DataModule, you are creating a new connection. It will only be a
matter of time, in this case until you crash the application by taking up
huge chunks of memory by creating these connections in a non threaded
manner (a new instance), This would also mean that the resolvers which are
independently connected to each database, would be constantly loaded. This
really sounds like your problem since it is a random occurance.
(4) Look at your ActionEvents and Listener classes. Do you have mutiple
instances of these classes defined in your jbInit() sections? JBuilder has
a {*word*193} habit of creating mutiple calls to ActionEvents and
WindoewListeners in your jbInit() section. Usually (but not always) this
ahhapend any time you click on a component that has an event connected to
it. This would mean the ActionEvents are firing multiple times, each time
you select one. That could cause all sorts of problems.
The stack Trace you get from the -verbose option, should give you some
clues. However the stack dump will be really long and I would suggest you
pipe the output to a file, rather than trying to track it down on the
screen.
If you have Enterprise Version, use the OptimizeIT profiling tool. Optimize
It, should reveal exactly what your problems are.
 

Re:Gui goes unstable

The question is indeed what information is relevant. In truth I'm wading
through many tens of thousands of lines of code written by our younglings
and somewhere one of them has made a mistake. Anyway thanks for your
thoughts it is always helpful to have someone elses perspective. The code
was written with JBuilder 7 without using the designers because we have
found them more trouble than they are worth. Running under 7 the app never
gets to the race condition due to memory leakage caused by the numerous bug
in the Borland libraries and it just dies out of memory. I'm currently
testing using a trial version of JBuilderX enterprise which we will be
upgrading to. Under X the memory leaks are largely fixed and the app will
run for long enough for the race condition to develop.
Some thoughts on your notes:
1) Could you give me a bit more detail on the problem with static methods,
I'm not quite sure what you mean. We only create the frames and query data
sets once, they are then re-used. So the problem is not creating new
instances of them.
2) Ditto
3) We only have one database connection and this is used by the three data
modules concerned. We do not load the data asynchronously.
4) Since we are not using the designers this should not be the case, but I
am checking the code.
I'll try running with verbose, at the moment I'm running with verbose:gc
because the original problem I was asked to fix was the memory leakage.
This is probably a very stupid question but how do you pipe the output to a
file under NT4? I hate to admit my ognorance but I've never had to do that.
I've tried to use OptimizeIt but the app becomes so slow that I've never
managed to get the race condition to develop. I'll have another go - I take
it you are suggesting that the memory profiler should show me what classes
are being created and where?
Whatever is causing this is clearly going wrong right from the start but
doesn't initially affect the app. Whatever it is gradually gets worse until
some critical point is reached. So gradually adding more listeners is a
posibility.
One final thought, if my gut reaction is correct and somehow we are firing
events recursively, where would they queue up and how could I get to peak at
the queue to see whats there?
I'm actually off sick today but I'll be having another crack at it tomorrow.
Thanks for you help
Simon
 

{smallsort}

Re:Gui goes unstable

Simon Bisson wrote:
Quote
We have a gui with half a dozen frames using JdbTables, JdbNavComboBoxes,
QueryDataSets and so on. Only one instance of each frame & query data set
is created (but the qds are refreshed in some of the frames). I can cycle
through the frames about 6 times. The first 4 times are fine. On the fifth
time the app seems to be slowing down. On the sixth time the app gets to
the point where I merely have to click on e.g. the down arrow at the right
of a JdbNavComboBox and the app seems to go into some sort of race
condition. The garbage collector shows that there is maybe 40Mb free on the
heap before I do the above click. The garbage collector starts immense
activity and shows that all the memory on the heap is being rapidly consumed
and the CPU is at 100%.
How do you know it's the garbage collector?
Are you doing straight JDBC anywhere? Are
you forgetting to close connections and
essentially running out of them in some
kind of connection pool manager?
--
Paul Furbacher (TeamB)
Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html
Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html
Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.
 

Re:Gui goes unstable

I'm running with -verbose:gc and I can see the garbage collector working
normally. Whatever causes this gradually gets worse and worse until a
critical point is reached. The behaviour I see is that many objects, which
are not collectable, are bring created on the heap. The garbage collector
does it's best but eventually runs out of memory. When it kicks off the app
is dead in a couple of seconds. It is always a swing event that starts it -
it doesn't seem to matter which one.
We only have one database connection which is used by several Query
Datasets. We are not using any "raw" JDBC.
"Paul Furbacher" < XXXX@XXXXX.COM >wrote in message
Quote
Simon Bisson wrote:

>We have a gui with half a dozen frames using JdbTables,
JdbNavComboBoxes,
>QueryDataSets and so on. Only one instance of each frame & query data
set
>is created (but the qds are refreshed in some of the frames). I can
cycle
>through the frames about 6 times. The first 4 times are fine. On the
fifth
>time the app seems to be slowing down. On the sixth time the app gets
to
>the point where I merely have to click on e.g. the down arrow at the
right
>of a JdbNavComboBox and the app seems to go into some sort of race
>condition. The garbage collector shows that there is maybe 40Mb free on
the
>heap before I do the above click. The garbage collector starts immense
>activity and shows that all the memory on the heap is being rapidly
consumed
>and the CPU is at 100%.

How do you know it's the garbage collector?

Are you doing straight JDBC anywhere? Are
you forgetting to close connections and
essentially running out of them in some
kind of connection pool manager?


--


Paul Furbacher (TeamB)

Save time, search the archives:
www.borland.com/newsgroups/ngsearch.html

Is it in Joi Ellis's Faq-O-Matic?
www.visi.com/~gyles19/fom-serve/cache/1.html

Finally, please send responses to the newsgroup only.
That means, do not send email directly to me.
Thank you.