First, I ran the test with your new tcp file less the unsupported property and it failed miserably. Not only did a putter take minutes to start, when it later got going it consumed memory in big chunks say 2-3 MB between gc updates.
Next, I looked at your modified testcase and added the Thread.sleep(5) to my own SimpleCacheTest.java after each put as you had done. In all fairness, that's probably a more realistic load than a continuous relentless put. I then ran the test with the fc-fast configuration. This time the memory consumption increases much more slowly and you can also see that the gc manages to free memory. However, the trend is still growing and after about 40 minutes both putters had consumed all JVM memory and a full gc was invoked. Next, I took your version of SimpleCacheTest.java (with the receiver flag = false, and the System.out.println output commented away) and your NetCache.java and reran the test with the fc-fast configuration. I should now be running virtually the same testbench as you (apart from the console output and your JBosscache 1.2.1 jar). When running two simple.bat putters simultaneously I eat up all 200 MBs of JVM memory in less than 5 minutes in each JVM triggering a full gc. Of course, after the full garbage collect the memory is cleaned up and in each putter the memory consumption is back to 25 MB after the gc. (And then starts to grow again). The problem is that in some app servers a full gc is something potentially dangerous since the full gc may totally shut down the JVM during the gc. Using e.g. Oracle 9ias the most likely result of a full gc is that the JVM is restarted which is something you don't want to happen in a heavily loaded enterprise application. What you need to do is to make the gc collect your JGroups garbage objects much more often. This is the problem with Java, in C++ you simply write "delete pObject" when you want to free memory, In Java you can't explicitly handle memory that way. Or maybe you can, in which case would be the solution you need to clean your JGroups objects? Another solution may be to handle memory more carefully in your JGroups stack and avoid using the new operator as often. Anyway, my conclusions at this point are the following: * repeated puts on the same key is not a recommended practice when using JBossCache (version 1.2) in a cluster. Apart from this oddity the cache seems to be working ok. * the fc-fast configuration seems to be most stable one and is preferred over UDP or TCP Best regards, Henrik Nyberg View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3869692#3869692 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3869692 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
