Help: Perl/Mapscript Bug?

[Stephen Woodbridge]

Resolution:

It looks like there are two problems here.

1) there is a bug in 4.0.1 where the shapefiles are not getting closed.
2) there is a separate bug on 4.0.1 that required the first
$layer-open(); because we had the TEMPLATE in the CLASS and not the
LAYER. This caused two copies of the shapefiles to get left open on
every hit.

To further compound this problem, we were running fastcgi, which kept
all the file handles open because the process lives beyond the request.

I added a TEMPLATE line to the LAYER, and a COLOR to the CLASS and was
able to get rid of the first $layer->open(), but I could not get the
files to close on 4.0.1. We added $layer->close() to no avail.

We upgraded to 4.4.2 and everything is working as expected.

Thanks for the help and suggestions, this list really rocks!

-Steve W.

Sean Gillies wrote:
> On May 5, 2005, at 11:21 AM, Stephen Woodbridge wrote:
>
>> Hi all,
>>
>> I have run into an interesting but NASTY problem with Perl/Mapscript
>> running in a fcgi process on Linux.
>>
>> Does anyone have any ideas?
>> Is this a bug that has been fixed in a later release?
>>
>> Particulars:
>>
>> Debian Woody and Mapserver 4.01 - yes it is old, but it is a production
>> system and we are concerned about the performance issues are in the
>> later releases.
>>
>> The problem is that this script is running as an apache fcgi process and
>> it is consuming all the system resources. An lsof shows that the
>> shapefiles are not getting closed after each hit. We have tried to close
>> the layer and undef the mapObj, but it does not fix the problem. It
>> seems mapscript is not closing the file handles!!!
>>
>> We are going to try and test this under 4.4.1 and 4.4.2 and see what
>> happens
>>
>> Any ideas?
>>    -Steve W.
>>
>
> Steve,
>
> I don't even keep the 4.0 source around anymore, so I'm looking at 4.2.
>  I don't think maplayer.c had too many changes in between.
>
> I suspect your problem is with the multiple calls to layerObj::open().
> On the second call, a new shapefileObj will be allocated and the layer's
> info pointer will be pointed to it, but it doesn't look like the
> pre-existing one is ever freed.  My comments continue below ...
>
>
>> the Perl code is like:
>>
>> sub query {
>>      my $latitude = shift;
>>      my $longitude = shift;
>>
>>      ## create new mapscript objec using appropriate mapfile
>>      my $map = new mapscript::mapObj($mapfile);
>>      return error("Can not open Mapfile: $mapfile") if not $map;
>>
>>      ## get streets layer
>>      my $layer = $map->getLayerByName('data');
>>      return error("Can not open Layer: data") if not $layer;
>>      $layer->{status} = $mapscript::MS_ON;
>>
>>      ## open the layer or the query will fail
>>      ## WHY DOES THIS NEED TO BE DONE HERE!
>>      $layer->open();
>>
>
> This is not necessary, and is probably the source of the leak.  I've
> never had problems querying a closed layer.
>
>>      ## build point obj using lat/lon
>>      my $point = new mapscript::pointObj();
>>      $point->{y} = $latitude;
>>      $point->{x} = $longitude;
>>
>>      ## now query the layer object using lat/longs
>>      $layer->queryByPoint($map, $point, $mapscript::MS_SINGLE, -1.0);
>>
>>      ## reopen layer to get results,
>>      ## you can't close it or it will lose the query info
>>      $layer->open();
>>      my $res = $layer->getResult(0);
>>
>
> Right.  Open the layer only to get the results.
>
>
>>      ## get shape obj
>>      my $shp = new mapscript::shapeObj($layer->{type});
>>      $layer->getShape($shp, $res->{tileindex}, $res->{shapeindex});
>>
>>      my $data;
>>      my $polyline = get_shp_xy($shp);
>>
>>      ## do stuff with polyline put results into $data
>>
>>      ## we tried   $layer->close() and undef $map here
>>      ## but it did not make a difference
>>
>>      return($data);
>> }
>>
>>
>
> Hope that helps,
>
>
> --
> Sean Gillies
> sgillies at frii dot com
> http://zcologia.com
>
>