zmailer memory leak status

[John Scharbe <jscharbe@globalvillag.com>]

When last we left, zmailer was leaking memory in large chunks.  

Since then, I have recompiled with the latest version of the 
toronto malloc routine as suggested and tested it.  At first
it appear to solve the problem.  I ran 1300 messages through
to local accounts and the memory leak was still there but 
significantly reduced, however, over the last two days, its
come back with a vengance (150MB) for one router process.

I can only infer that its related to non local traffic.

At present, I see two options for correting this problem:

1) try a different malloc routine as suggested in previous
   mail

2) Do a clean compile under the SUN development environment
   with clean SUN malloc's then track down and eliminate
   the memory leaks (I will probably add Testcenter from
   Centerline for this purpose).

I propose to do the later.

PS it appears that zmailer does not implment reliable signal 
handling, one more think to fix.

This leads to the following questions:

1) mia, indiatacted (he/she?) was working on a newer version
   does any one know what branch's of source have been created
   from the toronto base ? What's the feature differences ?  Any
   recommendation ?

2) I'm going to recompile on Solaris 2.3 (an AT&T 5.4 base system)
   I tend to target that enviroment instead of SUN 4.X, any 
   thoughts ?

Last some observations:

Some one mentioned that only thier first router process was working,
point in fact they all seam to work but only under heavy loads, so
on a system with light email loads, the first router accumulates 
most of the time.

Second,  it is painfully slow.  I will do some profiling but I 
suspect it related to the router CPU time and the heavy use of file
I/O (e.g.) heavy logging, lots of stat info on disk.

Moving forward, I'm thinking of the following changes:

1) add light weight threads to the router process, and clean up
   logging

2) Add a write through cache for status information

3) Utilize signals and rpcs to tell other processes when there 
   is work to be done instead of the file system

4) Implment a unifed logging archiecture

5) Develop a MIB-II interface and an Tivoli object management
   interface

Any thoughts about these ideals

Thanks,

John Scharber