I have a custom Java webapp that uses Java mapscript and is running with tomcat. Each flow from request to response is a single thread, but tomcat is able to process multiple concurrent requests if it receives them.
I was previously having a problem that I at first thought was a multithreading issue, but turned out to be a memory leak: http://trac.osgeo.org/mapserver/ticket/2525 http://www.nabble.com/thread-safety-to15514019.html I have patched my code and the memory leak is now solved. I can run fairly long stress tests (so far as long as 14 hours) with a client sequentially requesting maps and everything runs fine. But if I have my client make concurrent requests, the mapscript code inevitably throws a SIGSEGV, crashing the JVM and tomcat. This usually happens sometime within the first or second hour of my stress test. All times (5 so far), the stack trace has been entirely identical, starting with a Java mapscript call to mapObj.delete(). --- begin --- (msFreeLabelCacheSlot) mapfile.c:4068 (msFreeLabelCache) mapfile.c:4100 (msFreeMap) mapobject.c:98 (*) (delete_mapObj) mapscript/java/mapscript_wrap.c:1619 (**) (Java_edu_umn_gis_mapscript_mapscriptJNI_delete_1mapObj) mapscript/java/mapscript_wrap.c:19695 (***) code is compiled with -O2 (aside, is this possible to change when running configure?), so i'm not too surprised at possible slight differences in line numbers: (*) should probably be mapobject.c:96. (**) should probably be mapscript_wrap.c:1618 (***) should probably be mapscript/java/mapscript_wrap.c:19693 --- end --- I'm wondering if there is perhaps some lock that is needed with respect to the label cache that might be missing. Is there some way that I can disable the label cache (presumably at a cost of performance) to see if the crash still occurs? I see that a comment in mapthread.c notes: --- begin --- 1) It is currently assumed that a mapObj belongs only to one thread at a time. That is, there is no effort to syncronize access to a mapObj itself. --- end --- I am adhering to this. Each request is processed in a single thread, and that thread creates its own mapObj and calls delete() on it when done, and no other thread ever has access to the mapObj. I don't yet have a fully self contained test case for this using Java mapscript independent of tomcat, but I could work on creating one. I am running mapserver 5.0.0, locally patched to fix bug 2525 as noted above. This is on debian 3.1 (sarge), locally compiled with gcc 3.3.5, using locally compiled versions of GD 2.0.35 and AGG 2.5, and debian packages for everything else. My mapserver configuration is as follows: MapServer version 5.0.0 OUTPUT=GIF OUTPUT=PNG OUTPUT=WBMP OUTPUT=SVG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=THREADS INPUT=POSTGIS INPUT=SHAPEFILE The Java mapscript code was compiled with SWIG 1.3.24 and Sun Java 1.5.0_06. It runs with the same version of Java and with tomcat 5.5.17. It queries its data from a PostgreSQL/PostGIS database, uses projections, uses the AGG renderer, includes labels with TrueType fonts, and generates PNG output. I think that what I'm doing ought to be thread safe, although I can't say that 100% certain of that. Thanks for any help that anyone might be able to provide. - Rich -- View this message in context: http://www.nabble.com/missing-lock-in-mapfile.c%3AmsFreeLabelCacheSlot%28%29---tp15699786p15699786.html Sent from the Mapserver - User mailing list archive at Nabble.com. _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
