2008/11/24 Phil@Work phil@retailinfo.com.au:

Hi Igor, Thanks for the quick reply. Sorry if this is a silly question - how do i go about fixing this? :) I don't see any MA classes that respond to #terminate, i haven't seen any exceptions referring to #terminate, so i'm not sure how to start... Many thanks in advance. Phil

Well, as with any recursion (if it recursion) , find a repetitive pattern - then somewhere in it put check for a flag , which initially should be false, and set to true on first entry.

And, you don't have to look after #terminate implementors. When process terminates in squeak, it initiates the stack unwinding, so any #ensure: or #ifCurtailed: blocks get executed. There is plenty of them in Magma, and looks like one of them causing recursion.

Thanks Hernán - Much appreciated! On 24/11/2008, at 1:08 PM, Hernán Morales Durand wrote:

Hi Phil, We had the same problem with defunct Magma processes. To quick fix this we terminated the processes this way:

" Before evaluation be aware of other processes with the same priority... " ( Process allInstances select: [: aProcess | aProcess priority = 50 ] ) allButFirst do: [: ea | ea terminate ]

and reinstalled the previous release. Cheers

Hernán

Hi all, sorry to not have seen this thread sooner!

The unreleased processes is one of the unfortunate bugs I forgot to fix before letting 41 out the door. It *should* be cleared up now in the new 41.1 maintenance release from earlier today. If you have old ones still lying around,

MaStatHistory cleanUp

will eliminate them all gracefully.

It was my bad. The processes themselves are actually used to reset the statistical counters back to zero so the next five-minute period stats can be captured on their own. This information will then eventually be used in the charts of a "Monitoring Console" UI.

The bug was that I forgot to release those MaTimers (so the end gracefully) when sessions are disconnected, so it was very easy to accumulate quite a few.

I believe I have all of the proper release code in place, so while you will still see around* 44 Processes for each MagmaSession client (now priority 51 instead of 50, so easier to identify in the Process list), they will no longer accumulate ad infinitum. They are now appropriately de-allocated when disconnecting clients or shutting down servers.

- Chris

* MagmaSessionStatistics maintains 14 separate timings, plus one for each type of request that can be sent (MagmaRepositoryRequest allSubclasses size = 30) so about 44 processes for each MagmaSession client. Count about that many for each server process as well.

On Mon, Nov 24, 2008 at 7:49 AM, Göran Krampe goran@krampe.se wrote:

Hey!

Phil@Work wrote:

...

Hi All,

I've seen this answered in the archive a couple of months back, however the solution isn't working for me.

I have around 3000 processes that appear to be defunct timers - ie i've shutdown magma, thrown away the magma directory, started up squeak again, and... many thousands of magma processes - at one stage around 5000 processes!

First of all I do think the *idea* is to have "lots" of Processes - but I am not sure how many there should be, according to Chris.

I am currently trying out running a separate Magma server with Gjallar (seems to work fine now) and I have 1000-1400 (Process allInstances size) in the Seaside image.

...

still many thousands of processes.

Does anyone know how to clean up the mess?

I think Igor and the others refer to the earlier seen bug that started spawning Processes recursively until your image started feeling like glue. I haven't seen that bug in quite some time so I am not sure that is what you are seeing. And it was quite hard to break too if it grew too far.

regards, Göran

---

Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma