[mapguide-internals] TileService cache Question
trevor_wekel at otxsystems.com
Tue Mar 16 09:10:34 EDT 2010
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.
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.
// TODO: Handle the exception by displaying a tile with an error
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.
mapguide-internals mailing list
mapguide-internals at lists.osgeo.org
More information about the mapguide-internals