mgserver locks up when using AGG renderer

[jbirch]

In some cases, when zooming to large scales (depends on dataset and screen size), mgserver.exe enters a state where it locks up. It consumes 98% cpu, and can not be terminated with a ctrl-c when run interactively. This only occurs when using the AGG renderer; switching to GD prevents this behaviour.

The attached (or maybe hyperlinked if it's too big) data set can be used to exhibit this problem:

• Load the package hanging_ajax.mgp
• In Studio, open the weblayout to Library://ccgismap-ext/test/Layout/error_test
• Preview this layout in the AJAX viewer (from the link in the layout editor) and use the mouse wheel to zoom in in increments until the server stops responding.
• you may notice that at a particular scale, the feature no longer renders, though the server still responds. I saw this behaviour at about 1:100 on my 1280x1024 screen.

This problem was initially found by Jonathan Manafi, and has been verified by Jason Birch, for MGOS 2.0 RC4.

[zspitzer]

Using 2.0.0 on XP, I can reproduce the feature not being rendered at below about a scale of 100, however, the i did not experience any locking up or 99% CPU issues

The following error was logged in the server error.log

<2008-03-04T21:19:54> Anonymous

Error: Failed to stylize layer: mwa-ll27

An unclassified exception occurred.

StackTrace?:

• MgMappingUtil?.StylizeLayers? line 776 file d:\buildforgeprojects\mapguide_open_source_v2.0\build_23.8\mgdev\server\src\services\mapping\MappingUtil?.cpp Failed to stylize layer: mwa-ll27

An unclassified exception occurred.

[jmanafi]

I can confirm that the issue is still there in 2.0.1. I tried viewing this file, and under 1:100 scale, the server began consuming 50% of the CPU. If I tried to reload the page, sometimes it would sit at a loading screen, sometimes it would allow me to access the map again, and if I again zoomed to under 1:100, it consumed another 50% and stayed around 98-99% CPU.

[trevorwekel]

I can reproduce this defect and am working with Traian on a fix.

[jmanafi]

There was a bit more testing done under 2.0.2, with troubleshooting from Traian  http://www.nabble.com/what%27s-holding-people-back-from-upgrading-to-2.0--to19849764.html#a19867528

[waltweltonlair]

I just retested this against the current trunk code. I followed the steps to reproduce, but did not see any spikes in memory, Is there a special place where you have to zoom in? Or is this is no longer an issue in the current version?

[trevorwekel]

Hi Walt, I think did an initial investigation into this defect. Check to see if the data source has a Z-value.

LineBuffer* LineBuffer::Clip(RS_Bounds& b, GeomOperationType clipType, LineBufferPool* lbp)
{
    // We don't handle 3D clipping correctly yet
    // TODO: Implement 3D clipping if necessary
    if (hasZ())
        return this;

And I recall that I enabled clipping somewhere else in the stylization code base. There may be a work in progress patch on my old laptop. Check with Bruce. The code I was working on produced an unexpected clip boundary along the edge of the screen so I did not submit it.

[waltweltonlair]

Yes, the data has Z, and so in the past it would not get clipped due to the code you highlighted above. In r4226, however, I updated stylization so that z-values are ignored for 2D renderers, like AGG. As a result clipping now happens for this dataset.

Nevertheless, I tweaked the code so it was like before (with no clipping), and I could still not reproduce the problem.

Given the change in r4226, I'm prepared to close this ticket as fixed, unless someone can provide updated steps on how to reproduce this.