you're going to have to be more specific about this. In general, what every memory the JVM allocates will still belong to the VM until jmeter is restarted. That's normal JVM operation. In the typical case.
memory before test start - 40-45mb ( depends on system and physical ram) after test - 90mb Just because the JVM now hold 90mb, it doesn't mean jmeter is actually leaking anything. I've profiled jmeter extensively during the development of the distribution graph, tomcat monitor, webservice sampler and jms sampler. I can state with confidence the stock http sampler, webservice sampler and standard listeners do not have a memory leak. I typically profile jmeter with optimizeIt and watch both the heap activity and object count. normally, most jmeter components implement the clear interface to make sure objects are cleared, but it is ultimately up to the JVM to garbage the object and free the heap space. If you have a particular test plan that can reproduce the leak, please make a bugzilla entry and i will gladly look into it. keep in mind that until you "clear" things, jmeter will continue to hold on to the collected results. if you're using a custom plugin, it should implement the clear interface and method. If you're using jms, I am aware of memory leaks in orion jms client. I discovered a couple of bugs in orion's jms client in the process of profiling the new jms sampler in HEAD. thanks for taking time to post the question, it would really help to have more details or the exact test plan. peter On Wed, 1 Dec 2004 12:10:45 +0100, Giuseppe Ielpa <[EMAIL PROTECTED]> wrote: > Dear All, > > I noted that Jmeter manages memory in a bad flavour. > If I try to run a test, after its termination, > the memory is not freed. This is strange, since Jmeter is implemented > in Java. Anyway it is possible that some (global?) objects are not > cleared or deleted after the run, and remain active in a way that the > Garbage collector does not recognize them as garbage. > > Has any of you experimented a problem like this > > Best > > Giuseppe Ielpa > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
