Opened 12 years ago

Closed 12 years ago

#39 closed defect (fixed)

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

Reported by: tomfukushima Owned by: brucedechant
Priority: high Milestone: 1.2
Component: Feature Service Version: 1.2.0
Severity: blocker Keywords: GDAL thread model
Cc: warmerdam, jbirch External ID: 926433

Description

With MGOS 1.2.0 Beta 1, if you create a GDAL based layer and try to preview it, you will get a "The FDO provider thread model is not supported error".

There was some thread model work that was done in the server so I'll assign this to Bruce first and see what happens there.

Change History (11)

comment:1 Changed 12 years ago by anonymous

Cc: warmerdam added

comment:2 Changed 12 years ago by brucedechant

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.

comment:3 Changed 12 years ago by warmerdam

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.

comment:4 Changed 12 years ago by brucedechant

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

comment:5 in reply to:  1 Changed 12 years ago by robertbray

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.

comment:6 Changed 12 years ago by anonymous

Cc: jbirch added
Severity: majorblocker

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?

comment:7 Changed 12 years ago by 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.

comment:8 in reply to:  7 Changed 12 years ago by traianstanev

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.

comment:9 Changed 12 years ago by rexszeto

External ID: 926433

comment:10 Changed 12 years ago by brucedechant

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

comment:11 Changed 12 years ago by anonymous

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.