[mapguide-internals] Release of MGOS 1.2.0

[Jason Birch]

Sounds like a lot of work.

I think that in the interest of reducing changes to the 3.2.x branch,
and getting MapGuide out and stable, I agree with Frank's suggestion to
go with a OneTrueLock for now, single-queuing the provider for release.

I'd also really like to see fine-grained mechanisms introduced into the
3.3.x version, only locking what's necessary, so that we can wring as
much performance out of it as possible.  But stability for the coming
release is most important to me.

Jason

-----Original Message-----
From: Haris Kurtagic
Sent: Thursday, June 28, 2007 14:36
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