Yep you got me right, thanks. So Roderick Parks problem might come from his own code and not from the beanshell sampler itself. In order to be sure Roderick should create a heap dump of jmeter when the original memory problem occurs and than analyze to see if the leak came from his code / objects or from jmeter's.
Make sense? On Thu, Jun 21, 2012 at 6:08 PM, sebb <[email protected]> wrote: > On 21 June 2012 16:01, Shmuel Krakower <[email protected]> wrote: > > Sebb, > > Aside of compatibility, does it make sense that the "Reset > bsh.Interpreter > > before each call" will solve this kind of a problem? > > Not quite sure what you mean here. > The reset() function actually creates a new interpreter, thus allowing > GC to tidy up the old interpreter. > > > And if so, it might be caused by some kind of leak in the beanshell code > of > > the user and not necessarily due to bug in JMeter, right? > > Yes, the leak might be in user code or BeanShell itself. > > And if the leak is in BeanShell itself, maybe it will be fixed one day... > > > Shmuel. > > > > > > On Thu, Jun 21, 2012 at 5:47 PM, sebb <[email protected]> wrote: > > > >> On 20 June 2012 18:54, Roderick Parks <[email protected]> > >> wrote: > >> > I hit an interesting problem today where my test slowed to a crawl > after > >> > about just 6000 iterations (out of a total of about 500000 required) > >> > irrespective of the number of threads, delay timer or size of Java > heap > >> > space. The system was operating well within its CPU and memory limits. > >> > > >> > > >> > > >> > My test is trivial: replaying XML API requests from a CSV file after > >> > advancing the dates in the otherwise perishable samples. I use bean > >> > shell to modify the dates. > >> > > >> > > >> > > >> > I allowed the script to continue labouring and finally the JVM died: > "GC > >> > overhead limit exceeded". The solution was simply to check the "Reset > >> > bsh.Interpreter before each call" box on my bean shell sampler and all > >> > was well. > >> > > >> > > >> > > >> > The conclusion I have drawn from this is that garbage collection > becomes > >> > a very difficult task for the JVM if the bean shell interpreter is not > >> > reset, and ultimately, that is what caused the test to stall and the > JVM > >> > to die. In my experience, heap space exhaustion is the most common > cause > >> > of failures in JMeter, so having optimal garbage collection is very > >> > important. > >> > > >> > > >> > > >> > Therefore, I would suggest that the default "false" setting for > >> > resetting the bean shell interpreter in all the bean shell components > is > >> > actually not the sensible choice. Has this default been challenged or > >> > discussed previously? > >> > >> The default setting is necessary for compatibility, and cannot be > >> changed without potentially breaking some scripts. > >> > >> --------------------------------------------------------------------- > >> 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] > >
