Seems to me that the way to address the debugging issue is to write some documentation suggesting how to use the listeners for this purpose. And to let people know which Listeners need lots of memory.
There are perfectly good reasons for having a Tree View Listener in a Load Test Plan. e.g. it might be in a branch that is rarely taken. Remember also that Load Tests should only be done in non-GUI mode. I am opposed to thos change; it will cause more problems than it solves, and is the wrong way to approach the issue. On 11 March 2016 at 21:11, Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > Vladimir> If the only aim of creating a debug listeners menu is to avoid OOM, > Philippe>Not only this one. > > Can we start from the requirements then? (I might miss the original email) > > Philippe>The use case is "I want to debug my plan" > > I think the most surprising thing for newbies is that "listeners are > inherited". > Implementing pause/resume/breakpoint would be great. > > Have you considered creating duplicate entries for "View Results Tree"? > For instance, display it under current menu and under "debug ..." at > the same time. > > Philippe>I think when you use a View Results Tree even with logs, you are > trying to debug errors no ? > > View Results Tree can: > 1) "log all results". This is useful for debugging. > 2) "log errors only". It should skip successfull responses and log > only erroneous ones (e.g. the ones with failed assertions, etc). > > The second option is useful even for regular load testing, as it would > enable investigation of concurrency issues. > Number of errors should not be high => number of logged results would > not be high => no OOM, no much overhead. > > Otherwise you would have hard time trying to figure out why test fails > under load. > > Vladimir
