Opened 15 years ago

Closed 15 years ago

#1051 closed defect (fixed)

MapGuide exhausts FDO connections during Fusion selection

Reported by: jbirch Owned by: trevorwekel
Priority: high Milestone: 2.1
Component: Feature Service Version: 2.1.0
Severity: blocker Keywords:
Cc: greenmapsanmiguel, jng, tomfukushima, brucedechant, pagameba External ID:

Description

This problem was initially surfaced on the Users mailing list, and has been traced down a few false paths. ( #1039 , Fusion #229 )

After Andy's most recent email to the -internals list I spent some time trying to figure this out. I'd like to confirm that it was pretty easy for me to duplicate this problem in my environment:

  • Edit serverconfig.ini, setting DataConnectionPoolSize to 20
  • Restart MapGuide
  • Zoom in and start selecting

When I reach some small number of selections (15-20), no further operations work.

This is REALLY bizarre that the DataConnectionPoolSize affects this problem because I have the SDF provided excluded from connection pooling. (same as Andy indicated).

Just to try my hunch, I went through and changed all of my Fusion app's:

$map = new MgMap();
$map->Create($resourceService, $resourceID, $mapTitle);

$map = new MgMap();
$map->Open($resourceService, $mapName);
$map->Save($resourceService);

to the newer:

$map = new MgMap($siteConnection);
$map->Create($resourceID, $mapTitle);

$map = new MgMap($siteConnection);
$map->Open($mapName);
$map->Save();

This had absolutely no effect on the problem. So much for hunches.

I'm convinced that it's a problem inside of MapGuide that Fusion just happens to be exercising with its different selection methodology. I am also convinced that this is a regression; the exact same map and application running on a 2.0.x server do not exhibit this behaviour.

This is going to be a HUGE issue for anyone using Fusion. I'm at the end of things I can do to investigate this; I think it needs some internal uber-coder attention...

Attachments (1)

Ticket1051.patch (668 bytes ) - added by trevorwekel 15 years ago.
Patch for defect

Download all attachments as: .zip

Change History (13)

comment:1 by tomfukushima, 15 years ago

Note that there was a big change to the Fusion code in the way it does selection for 2.1. It's probably a but in the changes somewhere. I believe these changes were made by Ronnie Louie, Chris Claydon and Assefa to Fusion. I think that you might have to go back to the Fusion changelists to see what they were.

comment:2 by jbirch, 15 years ago

I'm not sure that the changes to Fusion are relevant to this problem. My Fusion application is 1.1 based, exhibits the problem when connecting to 2.1, and does not when connecting to 2.0.x. The only variable is this setup is the MapGuide version. I believe that Andy's application is 2.0 based and has the same behaviour.

An additional clue from the email:

I've been stepping through code and think I have isolated the problem.  
At this point I'm assuming that both of my issues (layers becoming
permenantly busy and running out of FDO connections) are related.   


The issues occur after use of setSelection, which uses both
SaveSelection.php and GetSelectionProperties.php.  Both of these
create a feature service then call GetExtents.  Here's a sample from
SaveSelection.php: 

$featureService = 
  $siteConnection->CreateService(MgServiceType::FeatureService); 

$oExtents = $selection->GetExtents($featureService); 

Creation of $featureService doesn't seem cause a problem, but as
soon as $oExtents is created the layer becomes busy and stays
busy until the MapGuide server is restarted. 

comment:3 by pagameba, 15 years ago

Does commenting out the call to GetExtents (and any related code) remove the problem? I seem to recall a recent ticket about GetExtents ...

comment:4 by jbirch, 15 years ago

Commenting out GetExtents breaks query.php (at least in Fusion 1.1) so I wasn't able to adequately test that. It looks like Andy did at Fusion 2.0 though.

More details based on Trevor's suggestion to look at the FDO cache info test page:

Every time I do a selection, the connection number goes up by one, and each one remains open and active. None of the other SDF layers on my map ever show up on this page, regardless of how quickly I refresh it.

Same test using exact same application and version of fusion against a 2.0.x server, and SDF excluded from the pooled providers, and no connections show up at all.

comment:5 by tomfukushima, 15 years ago

I was able to reproduce the problem in the latest trunk builds that I have and was able to reproduce the problem. Reverting back to an old version of Fusion did not fix the problem, so this is a new problem in the server.

comment:6 by trevorwekel, 15 years ago

Cc: pagameba added
Owner: set to trevorwekel
Status: newassigned

I have started some testing with the unofficial build Jason just posted. Jason was kind enough to supply me with a test map. The issue is not so cut and dry. It depends on the viewer used.

The Ajax viewer does not hold on to data connections during selection. Selections are highlighted correctly and the property pane updates correctly.

The Fusion viewer does hold on to data connections during selection. In addition, my testing seems to indicate that the selection is not drawn to the screen but the property pane is updated correctly.

I will keep working on it and update the ticket as I make further progress.

by trevorwekel, 15 years ago

Attachment: Ticket1051.patch added

Patch for defect

comment:7 by trevorwekel, 15 years ago

I have uploaded a patch to the ticket. It seems to correct the connection leak with the test map Jason sent me.

comment:8 by trevorwekel, 15 years ago

I will submit the fix once it has been confirmed and reviewed. I will also do the same submission for trunk once I've had time to download and compile the source tree.

comment:9 by tomfukushima, 15 years ago

Nice find. The fix looks fine to me. However, the patch doesn't use the correct spacing, can you ensure to set up your coding environment to use spaces and not tabs.

comment:10 by tomfukushima, 15 years ago

Also, is there a unit test that we can add that will catch problems like this in the future? (This is a general question that is open to anyone that might know or have the time to create it.)

comment:11 by trevorwekel, 15 years ago

Submitted to 2.1 branch in r4122

comment:12 by trevorwekel, 15 years ago

Resolution: fixed
Status: assignedclosed

Submitted to trunk in r4162

Note: See TracTickets for help on using tickets.