[MAPSERVER-USERS] missing lock in mapfile.c:msFreeLabelCacheSlot() ?

[Tamas Szekeres]

Rich,

I appreciate your efforts very much to sort these things out. I wish
we ever had a systematic multithreaded test case for the Java/C#
bindings with a fair amount of the coverage for the most fundamental
parts of the project. I'd feel quite inclined to open up a GSoC
project to implement a proper test environment where the potential
issues would be more discoverable.

I think the problem you described is weird enough for trying to think
about it further. The fact that the symptom is going towards another
place indicates me that the source of the issue is in a quite
different place.

Let us know if you have a further suspicion about something that
should be fixed in mapserver.

Best regards,

Tamas


2008/2/29, rich.fromm <nospam420 at yahoo.com>:
>
>
>  Tamas Szekeres wrote:
>  >
>  > You can probably control the caching effect by setting LABELCACHE OFF for
>  > all of layers. However I'm a bit hesitant to think that this is due to a
>  > missing lock around the labelcache itself since it doesn't contain static
>  > variables.
>  >
>
>
> I think you might be right, and that this crash might be another red
>  herring.
>
>  What I'm doing here is stressing the limits of the system to see what it can
>  handle.  There's various interactions between mapserver, the JVM, tomcat,
>  and
>  postgres, and when things go badly, it's not entirely clear what's the cause
>  and what's the effect.
>
>  I tried a few related tests:
>
>  1) I commented out all LAYER's that had any LABEL declarations.  In this
>    instance, tomcat indeed did NOT crash.  However, under stress there were
>    problems reported by tomcat and by postgres, but that's (sort of) okay.
>
>  2) I kept all of the LAYER's, but for those with LABEL declarations I set
>    LABELCACHE OFF.  The previous crash at mapfile.c:msFreeLabelCacheSlot()
>  did
>    NOT occur.  However, intead, there was a new crash:
>
>  (msClipPolygonRect) mapprimitive.c:605
>  (msDrawShape) mapdraw.c:1609
>  (msDrawVectorLayer) mapdraw.c:887
>  (msDrawLayer) mapdraw.c:718
>  (msDrawMap) mapdraw.c:432
>  (mapObj_draw) mapscript/java/mapscript_wrap.c:1714
>  (Java_edu_umn_gis_mapscript_mapscriptJNI_mapObj_1draw)
>  mapscript/java/mapscript_wrap.c:20612
>
>    But again this coincided with other things going badly under stress, so
>  I'm
>    not really sure if mapserver is to blame.  Ideally, tomcat and the JVM
>    should never crash.  If things go badly, the system should become less
>    responsive, and possibly refuse additional requests, or cancel existing
>    ones.  Crashing is clearly a wrong thing to do with respect to
>  correctness.
>    But given the nature of what I'm seeing, it's not clear to me that
>    mapserver is the piece at fault.
>
>  I've spent some time trying to tune tomcat and postgres and some OS
>  parameters
>  a bit.  While I'm still having a few issues, some of which might (or might
>  not) be genuine mapserver issues, now that the system is tuned better, I'm
>  not
>  seeing any more JVM crashes, even under heavy load.  (Although it might just
>  be that the definition of "heavy" has shifted higher, and I'm no longer
>  stressing things that much relative to that.)
>
>  Anyway, I will deal with the issues that I am having in separate mailing
>  list
>  threads.  But for the time being I think that maybe my original concern here
>  is a non-issue.  I'll reply back with more details if I see any more
>  observations that cause me to think differently.
>
>  - Rich
>
>
>  --
>  View this message in context: http://www.nabble.com/missing-lock-in-mapfile.c%3AmsFreeLabelCacheSlot%28%29---tp15699786p15748847.html
>
> Sent from the Mapserver - User mailing list archive at Nabble.com.
>
>  _______________________________________________
>  mapserver-users mailing list
>  mapserver-users at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/mapserver-users
>