Mapscript in mod_perl: frequent errors in mapObj->new

[Stephen Lime]

Correct me if I'm wrong but it seems to me that the mapObj constructor
shouldn't be re-entrant. The mapObj is reusable without re-reading from
a file. Some things need to be reset for each map but that will always
be the case: scale, extent, cellsize and layer status are examples.

I'm not a mod_perl or fastCGI expert. I assume there is a section for
initialization, that's where the new mapObj happens. Then there must
a loop handling execution. Question is what happens to the mapObj
each run, is a copy made, is it truly shared or what? Anyone know for
sure. Once that is understood I (think) can work around it to preserve
that original state of the mapObj. Memory leaks are another matter.

Steve


Stephen Lime
Internet Applications Analyst

Minnesota DNR
500 Lafayette Road
St. Paul, MN 55155
651-297-2937

>>> <imap at chesapeake.net> 06/08/00 02:28AM >>>

Markus/MapServer List,

On the topic of mod_perl problems...  a similar experience.

A client of mine tried to run under fastCGI, but Steve reports a
memory leak with PIXMAP symbols and we pretty much concluded that
mapObj->new is not reiterate.  That never did work for us.
It would be ideal to instantiate the mapfile/symbols only once 
and crank out mapObjects over and over via mod_perl or fastCGI.  
Probably all that is needed is some initialization and free()s 
to solve the issues.   That request gets deferred to Steve
for the TODO list.

After testing fastCGI, they had some success getting *very* quick
map generations.... but they backed off the idea until there is 
some resolution to the mapObj->new and memory leak malfuntions.
I know it was eventually consuming all of the available RAM on 
the machine as a bad side effect.  I'll ask Jim to elaborate 
on the details on the testing.

along the performance issues, the thing that would make a fastCGI
mod_perl configuration wildly successful is to snap-to quantified
zoom/panning ratios so that you build a decent cache of images.
That has been somewhat tested and for a high volume application,
I think that is the way to go.

Regards,

Chris Stuber (mapsurfer)
Silicon Mapping Solutions, Inc.
410-257-3187



Markus Spring wrote:
> 
> Hi list,
> 
> unfortunately there is no further info. In the http_error.log it
> tells only the line, in some very rare cases it mentions an ioctl
> problem (in german, as I use a german SuSE Linux) and then even the
> command line script will hang until I kill the http processes.
> 
> It looks to me as if there is a file close/lock problem with the mapfile
> itself,
> but I do not understand enough C to add some debugging messages.
> 
> Kind regards - markus