Hi Vladimir, Thanks for your note. The aim is not only to avoid OOM, it is to "ease" usage. User wants to debug his script, he knows he can use listeners in "Debug Listeners".
> 1) Such a split would complicate day-to-day activities since noone would > remember which listeners are filed under which menu. True > 2) I'm not sure there is a consistent way to tell if a particular listener is a "debug" listener or not. In other words, "debuggness" of a listener might depend on the configuration. For instance, "View results in tree" is somewhat fine if configured to log errors only. I think when you use a View Results Tree even with logs, you are trying to debug errors no ? > 3) I think UI should be designed around use cases. I'm not sure there's a case like "I need a debug listener, thus I open <<debug listeners>> menu". The use case is "I want to debug my plan" You can answer then why don't you put Debug Sampler in it, you would be right :-) > If the only aim of creating a debug listeners menu is to avoid OOM, Not only this one. > then other ways should be explored: A1) Store just 50MiB of "View Results Tree" data, then start to drop new data. A2) Mark problematic listeners (and parent nodes in tree) with some kind of red. On Fri, Mar 11, 2016 at 9:45 PM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Philippe> I attached screenshots to : > > I think there are better ways to achieve the same goal. > See https://bz.apache.org/bugzilla/show_bug.cgi?id=59157#c3 > > Vladimir > -- Cordialement. Philippe Mouawad.
