xmedeko

Hello, JasperReports heavily use ThreadLocal and static HashMaps which may cause memory leaks in the servlet containers. I think the JasperReports configuration and startup should be redesigned and the good examples is a Hibernate project. It uses: Configuration (immutable, thread safe) -> SessionFactory (thread safe) -> Session (thread unsafe). So the SessionFactory is created just one per application (stored it the static variable, servlet context or bound to the JNDI. The JasperReponts could may use Configuration (immutable, thread safe) -> ReportFactory (thread safe) -> new JasperReport (thread unsafe). All the resources, which are now cached in the ThreadLocal or static HashMaps would be cached in the Configuration or ReportFactory. Also, some utils to bind the ReportFactory to the JNDI would be nice. The JNDI may simplify usage of JasperReports in JEE environment. Cheers Andy

I apologize, it seems that SimpleFontExtensionHelper was not a source of the leak in my application. The ThreadLocal->SoftReference just holds the undeployed application in the memory for a few minutes. (Which is not nice, anyway.) No I have a probem with the sun.awt.AppContext.getAppContext() memory leak, since JasperReports uses awt fotnts to measure text width. Grrr, this bloody Java class loader hell.

Submitted bug http://jasperforge.org/projects/jasperreports/tracker/view.php?id=5164

I have found one more leak in SimpleFontExtensionHelper. If you make put SoftReference into the ThreadLocal then it is still memory leaking, since there is a circular reference! Furhemore, I if understand the code in net.sf.jasperreports.extensions.DefaultExtensionsRegistry.loadRegistries() - it right, then the SimpleFontExtensionHelper is initialized just once per class loader. So it is a nonses to cache its instances in ThreadLocal. Just create it, use it and forget it. No problems, no leaks.

Hello JasperReports developers, are you going to solve these redeploy memory leaks in JasperReports some day? May some financial contribution to your project encourage you to take interest in these nasty things? /tools/fckeditor/editor/images/smiley/msn/wink_smile.gif I have already submitted two pathes fixing these memory leaks, but none of them has been accepted up to now (version 4.0.0). At least the BorderOffset patch is not breaking any original functionality. I am asking epsecially to know If we can hope once these leaks will be solved or if we should change our deployment & release process to take into account and restart our server before each redeploy. Thanks Andy

Hmm, version 3.7.5 released and the memory leaks are not fixed there :-(

May it be redeploy leak? http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=76267

BTW. may static ConcurrentHashMap do the job? As a value, put Boolean.TRUE. It should not leak, I hope.

This is blocker for using JasperReports in JBoss and other containers which uses hot redeploy. So I have changed the severity to critical. Please, use ThreadLocal sparingly and with a big care. Take a look at http://xmedeko.blogspot.com/2010/02/java-web-container-hunting-redeploy.html. This bug is caused particularly by static ThreadLocal inner class, see http://crazybob.org/2006/02/threadlocal-memory-leak.html. This bug can be easily solved (I'll post the fix later). But I mean, the ThreadLocal in the JRFontUtil has a functionality just to limit number of WARN logs - in my opinion, it would be best to remove the ThreadLocal from this class completely. Why? 1. It does not improve any functionality, just causes problems 2. Some web servers, like Tomcat, use thread pool. So, if you do not clean the ThreadLocal after the request finishes, then the HashSet with missing fonts will occupy the memory forever (until the web server shut downs). E.g. if the pool has 300 threads and the JRFontUtil.threadMissingFontsCache occupy 1kB, then after some time the 300kB of memory is wasted.

I have set net.sf.jasperreports.evaluator.class.reference.fix.enabled=false in the jasperreports.properties and now it is not, hopefully, leaking. i think there are more memory leaks in the code (e.g. http://jasperforge.org/projects/jasperreports/tracker/view.php?id=3084), but I just do not use this code.

Hi, I have a text field in the report header $P{DESC}. Bellow this field are a few more elements in the header. Very often it is just a few words - it fits into one line. But occasionally it need more lines. I have switched on the isStretchWithOverflow="true" and it works fine for this field, but it "overwrites" the elements bellow it. Is there any way, how to automatically shift the elements, if one field is stretched? Thanks very much Andy

Hi, I have looked in the JRAbstractJavaCompiler source and IMHO PROPERTY_EVALUATOR_CLASS_REFERENCE_FIX_ENABLED does nothing, because only classFromBytesRef.set(...) is called, never classFromBytesRef.get(). If I am right, please remove the PROPERTY_EVALUATOR_CLASS_REFERENCE_FIX_ENABLED since it causes memry leaks in the web servers. Thanks

See http://jasperforge.org/projects/jasperreports/tracker/view.php?id=4882 Unfortunatelly, there are even more ThreadLocal memory leaks in JasperReports :-(

Hi, I have fixed that, see http://jasperforge.org/projects/jasperreports/tracker/view.php?id=4768 Unfortunatelly, there are more ThreadLocal memory leaks in JasperReports :-(