Opened 10 years ago

Closed 8 years ago

#459 closed defect (fixed)

mgserver locks up when using AGG renderer

Reported by: jbirch Owned by: waltweltonlair
Priority: medium Milestone:
Component: General Version: 2.0.0
Severity: major Keywords:
Cc: jmanafi External ID:

Description

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.

Attachments (1)

hanging_ajax.mgp (2.1 MB) - added by jbirch 10 years ago.

Change History (9)

Changed 10 years ago by jbirch

Attachment: hanging_ajax.mgp added

comment:1 Changed 10 years ago by 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?:

An unclassified exception occurred.

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

comment:3 Changed 10 years ago by trevorwekel

Owner: set to trevorwekel
Status: newassigned

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

comment:4 Changed 10 years ago by 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

comment:5 Changed 8 years ago by 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?

comment:6 Changed 8 years ago by trevorwekel

Owner: changed from trevorwekel to waltweltonlair
Status: assignednew

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.

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

comment:8 Changed 8 years ago by waltweltonlair

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