Richard,
I'm not sure whats causing this? Could you try it in Jetty to see if
its a tomcat problem? You should just be able to decompress the .war
and have jetty run it.
Someone else was reporting VM problems with fonts & tomcat, perhaps this
is the same problem?
dave
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
Le Mardi 6 Septembre 2005 18:50, dblasby@anonymised.com a écrit :
Richard,
I'm not sure whats causing this? Could you try it in Jetty to see if
its a tomcat problem? You should just be able to decompress the .war
and have jetty run it.Someone else was reporting VM problems with fonts & tomcat, perhaps this
is the same problem?
Sounds like !
Here is the stack trace I have got with tomcat 5.5.7 and JVM 1.5.0 :
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0x503293f2, pid=1355, tid=39976
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode)
# Problematic frame:
# C [libfontmanager.so+0x463f2] Java_sun_font_FileFont_getGlyphImage+0x174
#
# An error report file with more information is saved as hs_err_pid1355.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
Part of the log file is :
...
j
org.geotools.renderer.lite.LabelCacheDefault.overlappingItems(Ljava/awt/font/GlyphVector;Ljava/awt/geom/AffineTransform;Ljava/util/List;)Z+45
j
org.geotools.renderer.lite.LabelCacheDefault.end(Ljava/awt/Graphics2D;Ljava/awt/Rectangle;)V+260
j
org.geotools.renderer.lite.LiteRenderer2.paint(Ljava/awt/Graphics2D;Ljava/awt/Rectangle;Lcom/vividsolutions/jts/geom/Envelope;)V+366
j
org.geotools.renderer.lite.LiteRenderer2.paint(Ljava/awt/Graphics2D;Ljava/awt/Rectangle;Ljava/awt/geom/AffineTransform;)V+163
j
org.vfny.geoserver.wms.responses.DefaultRasterMapProducer.produceMap(Lorg/vfny/geoserver/wms/WMSMapContext;)V+211
j
org.vfny.geoserver.wms.responses.GetMapResponse.execute(Lorg/vfny/geoserver/Request;)V+415
j
org.vfny.geoserver.servlets.AbstractService.doService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Lorg/vfny/geoserver/Request;)V+146
j
org.vfny.geoserver.servlets.AbstractService.doGet(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+193
...
I will try to report the bug to apache group.
dave
didier
Le Mardi 6 Septembre 2005 18:50, dblasby@anonymised.com a écrit :
Richard,
I'm not sure whats causing this? Could you try it in Jetty to see if
its a tomcat problem? You should just be able to decompress the .war
and have jetty run it.
Test done, almost same result 
With Jetty, the amount of RAM/swap does not evolve much during processing. The
JVM crashes, but Jetty keeps on running eating 75-90% of the CPU without
responding to further requests.
With Tomcat, the amount of RAM/swap raises till reaching the total available.
The JVM crashes, tomcat stops.
Both JVM 1.4.2 and 1.5.0 crash.
The JVM logs (for both tomcat and jetty) have been submitted to Sun Bug
Report. I am not sure there will be a fix ...
I am still wondering why this happens :
- we use text rendering for some attributes without problem (like road
numbers, place names);
- we use text rendering for some attributes : crash.
Mainly the differences are in :
- the density of labels to render and therefore the collisions between them;
- the complexity of rendering : perpendicular to linesegment, offset around
label;
- the label are long with regard to the geometry they labelled.
Is there any means by which we can avoid reaching this situation ?
dave
didier
Quoting Richard didier <dgr@anonymised.com>:
Le Mardi 6 Septembre 2005 18:50, dblasby@anonymised.com a écrit :
> Richard,
>
> I'm not sure whats causing this? Could you try it in Jetty to see
if
> its a tomcat problem? You should just be able to decompress the
.war
> and have jetty run it.Test done, almost same result
With Jetty, the amount of RAM/swap does not evolve much during
processing. The
JVM crashes, but Jetty keeps on running eating 75-90% of the CPU
without
responding to further requests.
With Tomcat, the amount of RAM/swap raises till reaching the total
available.
The JVM crashes, tomcat stops.
Both JVM 1.4.2 and 1.5.0 crash.The JVM logs (for both tomcat and jetty) have been submitted to Sun
Bug
Report. I am not sure there will be a fix ...I am still wondering why this happens :
- we use text rendering for some attributes without problem (like
road
numbers, place names);
- we use text rendering for some attributes : crash.Mainly the differences are in :
- the density of labels to render and therefore the collisions
between them;
- the complexity of rendering : perpendicular to linesegment, offset
around
label;
- the label are long with regard to the geometry they labelled.Is there any means by which we can avoid reaching this situation ?
What about trying a different JVM implementation? I believe IBM has
one, and there should be a few others... Checking that will at least
confirm/deny if we are doing something majorly wrong - though I can't
imagine what that would be.
Chris
>
> dave
>didier
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/