[mapguide-internals] Release of MGOS 1.2.0

[Andy Morsell]

I am still seeing instability and lockups with the patched dll's.  The
instability is definitely related to the raster layer in this particular
map.   I am rebooting that server now as I know we saw a period of increased
stability after initially applying the patches.


Andy 

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: Thursday, June 28, 2007 2:36 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

I wouldn't like to jump ahead too much. 
What I saw when I was looking at it, If there are multiple sessions to
MapGuide there will be multiple threads using same FDO GDAL connection.

In FDO GDAL provider there is data cache which gets allocated/reallocated
and in multi user session's memory gets corrupted.
That part of provider was certainly not working properly if same connection
is used in several threads.

What I did was adding thread guards around memory allocation's in provider
and MapGuide/GDAL looks much more stable now.
Coleagues of mine have put in production two MapGuide sites in last week and
without GDAL patch MapGuide stopped almost regularly in mutliuser access.
After applying patch it looks like working ok.

I heard about this problem just few days ago and I had very limitted time to
look at it so certainly it would be necessary to look more into it before
getting any real conclusions.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Bruce
Dechant
Sent: Thursday, June 28, 2007 10:09 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

Multiple threads should not be accessing the GDAL provider concurrently,
however, when one thread is finished another thread can start to use the
GDAL provider and hence the same cached FDO connection. This might be the
"multiple" threads you are seeing. Is it not safe for the server to reuse an
existing GDAL FDO connection via one thread at a time or is it safer to
always start with a brand new GDAL FDO connection?

Thanks,
Bruce

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: June 28, 2007 1:57 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

Yes, there are multiple multiple threads sharing same connection to
provider.

Haris

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Tom
Fukushima
Sent: Thursday, June 28, 2007 9:49 PM
To: MapGuide Internals Mail List
Subject: RE: [mapguide-internals] Release of MGOS 1.2.0

I thought we had eliminated the multithreaded access to the FDO GDAL
provider; i.e., all access to the GDAL provider has been serialized.  If the
MapGuide server is still accessing the FDO GDAL provider simultaneously with
multiple threads, then there is a defect in the server.  We should fix the
server in this case.  Haris, have you seen where the server is failing to
serialize the access?

Tom

-----Original Message-----
From: mapguide-internals-bounces at lists.osgeo.org
[mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Frank
Warmerdam (External)
Sent: Thursday, June 28, 2007 1:20 PM
To: MapGuide Internals Mail List
Subject: Re: [mapguide-internals] Release of MGOS 1.2.0

Folks,

In discussions with Haris, it has become clear to me that the stability
problems relate to using fdogdal in multithreaded fashion with no internal
serialization.

The underlying GDAL library is "fairly" threadsafe as long as only one
thread at a time is accessing a given dataset.  But even that is not at all
assured under the current use pattern.

I think we need to put a BigLock (tm) around GDAL in fdogdal 3.2.2 and a
finer grained locking system in fdogdal 3.3 (trunk).

We could use Haris' patch though from a quick description it does not sound
to me like it is comprehensive.  I'm also willing to prepare a fix for this
if someone can test it heavily.

I'd add that there is no (apparent) way of testing multithreaded access in
the current regression tests for FDO which is a bit unfortunate.

Best regards,
-- 
---------------------------------------+--------------------------------
------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo,
http://osgeo.org

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

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

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