"thread model is not supported" error when previewing GDAL based layers

The minimum thread model supported by the MapGuide? server is FdoThreadCapability?_PerConnectionThreaded because FdoThreadCapability?_SingleThreaded impacts the server performance significantly due to having to block all the server's threads using the single threaded provider. The current server core is not designed to restrict this type of provider threading and therefore the minimum FdoThreadCapability?_PerConnectionThreaded is now enforced.

My suggestion is to make the GDAL provider thread safe so that it can work within a multi-threaded server.

Bruce,

I would appreciate some details on what guarantees the fdogdal provider is expected to offer in order to be PerConnectionThreaded?.

It would also be gratifying if someone on the mapguide team actually used the fdogdal provider on occasion so these things would be evident before the software reaches user hands.

It should be noted that the only way that fdogdal can guarantee multi-threaded safety is to strictly manage an internal mutex to keep things single threaded. Ultimately I think it would be better for the server software to maintain this.

Frank,

The FDO team would be able to best answer your first question.

You are correct Frank as we should have caught this sooner. We are still learning. :)

By adding a mutex to essential block everything inside the GDAL provider to simulate a singled threaded provider is not the right solution in order to be compliant. Ideally, you only want to block when absolutely necessary and not for everything. This will allow maximum performance and will allow the server to take full advantage of the provider.

If you have any threading questions I would be more then happy to discuss them with you via email or phone.

Thanks, Bruce

I think we need to protect the server against any and all potential problems. That means putting code in the server that protects it from providers that declare themselves less than per connection threaded.

The primary motivation is that some legacy libraries are often used in providers and there is simply no way to make them thread safe without completely re-writing them from scratch. We have to be more format friendly than that or users will simply find another technology that allows them to use their format.

I consider this to be a blocker. We can't release a 1.2.0 without Raster support and maintain credibility.

I'd imagine that this might affect the OGR provider as well?

The OGR provider should be marked as single threaded unless it internally serializes all access to OGR. No meaningful work has been done on multithreading support in OGR.

Replying to warmerdam:

The OGR provider should be marked as single threaded unless it internally serializes all access to OGR. No meaningful work has been done on multithreading support in OGR.

I haven't seen reports of crashes of this nature with the OGR provider, so I'd rather not make it single threaded at this point. And since I'm publicly stating this, I expect that by Murphy's law we should get a crash report tomorrow.

This has been fixed with RFC19 submission. http://trac.osgeo.org/mapguide/wiki/MapGuideRfc19