20 Dec
2006
20 Dec
'06
2:39 p.m.
---------- Forwarded message ----------
From: Thomas Koschate <koschate(a)gmail.com>
Date: Dec 20, 2006 2:34 PM
Subject: [Seaside] Magritte for VisualWorks
To: seaside(a)lists.squeakfoundation.org
I've released a reasonably functional port of Magritte into the Cincom
public StORE. Load MagritteForVisualWorks - it will prompt you to
load any further required parcels. There's some chaff left from stuff
that isn't supported in VisualWorks, but nothing that will impede
functionality.
--
============================================================
Thomas Koschate
_______________________________________________
Seaside mailing list
Seaside(a)lists.squeakfoundation.org
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
2 Jan
2 Jan
10:57 a.m.
New subject: Image size growing very fast
Hello,
I've had an image (based on the one from Ramon Leon) growing
from 30 MB to 675 MB in a very short time when developing an
application with Magritte (Magritte-Model-lr.228,
Magritte-Seaside-rjl.204, Seaside2.7a1-lr.137).
It has become rather unresponsive, and when trying to find out
where the memory was used a LowSpaceDebug.log was created.
Any clues?
Stephan Eggermont
1:21 p.m.
New subject: Image size growing very fast
I've had an image (based on the one from Ramon
Leon) growing
from 30 MB to 675 MB in a very short time when developing an
application with Magritte (Magritte-Model-lr.228,
Magritte-Seaside-rjl.204, Seaside2.7a1-lr.137).
It has become rather unresponsive, and when trying to find out
where the memory was used a LowSpaceDebug.log was created.
Usually this should not happen.
Any clues?
Things you might want to check:
1. Open the process browser and check if there are any runaway
processes, if so there must be an unconditional recursion somewhere
in your application. This can also happen if you have accidently
defined descriptions that depend on each other (reference descriptions).
2. Evaluate "WARegistry clearAllHanders. Smalltalk garbageCollect".
If this reduces the image size then your sessions somehow reference a
lot of data. This can happen if you have an OODB and somehow pull-in
a copy of a huge amount of data for every session.
3. Evaluate "MCFileBasedRepository flushAllCaches. Smalltalk
garbageCollect".
Also search the Seaside mailing-list. There were a couple of threads
about reducing the image size with other solutions ...
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
4 Jan
4 Jan
3:31 p.m.
New subject: Image size growing very fast
On Tue, Jan 02, 2007 at 01:21:36PM +0100, Lukas Renggli wrote:
Things you might want to check:
1. Open the process browser and check if there are any runaway
processes, if so there must be an unconditional recursion somewhere
in your application. This can also happen if you have accidently
defined descriptions that depend on each other (reference descriptions).
Uhhm, how do I see if a process is runaway? It has to be, as the
task manager shows 50% CPU use (dual core), and Mem usage keeps
growing. I have about 15 minutes to do something in the image before
it crashes.
Stephan
3:42 p.m.
New subject: Image size growing very fast
Uhhm, how do I see if a process is runaway? It has to
be, as the
task manager shows 50% CPU use (dual core), and Mem usage keeps
growing. I have about 15 minutes to do something in the image
before it crashes.
Usually a few seconds are enough to save an image ;-)
If you can mail it to me or put it online somewhere (compressed), I
can have a look.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5:50 p.m.
New subject: Image size growing very fast
2007/1/4, Stephan Eggermont <stephan(a)stack.nl>nl>:
On Tue, Jan 02, 2007 at 01:21:36PM +0100, Lukas
Renggli wrote:
Constant 50% on a dual core cpu = runaway process
Philippe
Things you might want to check:
1. Open the process browser and check if there are any runaway
processes, if so there must be an unconditional recursion somewhere
in your application. This can also happen if you have accidently
defined descriptions that depend on each other (reference descriptions).
Uhhm, how do I see if a process is runaway? It has to be, as the
task manager shows 50% CPU use (dual core), and Mem usage keeps
growing. I have about 15 minutes to do something in the image before
it crashes.
6:38 p.m.
New subject: Image size growing very fast
1. Open the
process browser and check if there are any runaway
processes, if so there must be an unconditional recursion somewhere
in your application. This can also happen if you have accidently
defined descriptions that depend on each other (reference
descriptions).
Uhhm, how do I see if a process is runaway? It has to be, as the
task manager shows 50% CPU use (dual core), and Mem usage keeps
growing. I have about 15 minutes to do something in the image before
it crashes. 1. Open the process browser and check if there are any
runaway
processes, if so there must be an unconditional recursion somewhere
in your application. This can also happen if you have accidently
defined descriptions that depend on each other (reference
descriptions).
In your case there was a process trying to validate descriptions that
circularly reference each other. Unfortunately Magritte does not
detect such situations automatically. I didn't look at your code, but
there are certainly different possibilities to solve the problem:
- Break circular references in your static or dynamic descriptions
explicitly (this is what I suggest and what I do in such cases)
- Change the validation implementation to not follow reference
descriptions or (better yet) implement it so that it doesn't validate
the same object multiple times.
PS: I will send you a link where you can download the working image
in private.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6315
days inactive
6330
days old
6 comments
4 participants
participants (4)
-
Lukas Renggli -
Lukas Renggli -
Philippe Marschall -
Stephan Eggermont