[mapguide-internals] TileService cache Question

[Trevor Wekel]

Hi UV,

If MgServerTileService::DetectTileLockFile finds an existing lock file, it waits for 120 seconds for the lock to free up before returning.  If the lock has not freed up after two minutes, then the render has probably failed and it is reasonable to blow the lock away and retry.

Regards,
Trevor

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of UV
Sent: March 15, 2010 9:45 AM
To: MapGuide Internals Mail List
Subject: [mapguide-internals] TileService cache Question

Trying to understand parallel overlapping tile requests to the tile 
service in preparation of meta tiling.

line 321-326 ServerTileService.cpp:
   // If there is a dangling lock file, then attempt to remove it.
    if (DetectTileLockFile(lockPathname))
    {
        // TODO: Handle the exception by displaying a tile with an error 
message?
        MgFileUtil::DeleteFile(lockPathname, true);
    }


I dont understand this logic... If someone has made the request for my 
tile already should I not wait instead of removing the lockfile?
Checking the time stamp of the lockfile would be a practical way to 
determine if its worth waiting......

The logic shown above seems to assume that it is an erroneous state to 
request a tile while it is computed.
In a multi-threaded server I can easily create scenarios where this 
could happen and a retry would be a smarter reaction to a found lockfile.

Any ideas?

_______________________________________________
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapguide-internals