On 19 August 2013 08:51, Danny Lade <[email protected]> wrote: > Before we have written our own SampleSender we tried this one. > > What makes it most worse is the fact that it stores the whole response body. > Therefore rather small tests runs into OutOfMemory if the bodies are big > (JSON/HTML). > Additionally it blocks the whole process because the sample store is > (unnecessarily) synchronized.
There is one class instance per Listener (in test plan or created by using -l flag). This is shared between threads, and testEnded uses a different thread, so access to the store must be synchronised. Both to ensure the the store is updated safely and to ensure safe publication. > In my opinion the only useful way to use a HoldSampleSender is one based on > statistical data mining. Good point; it could be useful to create a new version for that, as it would avoid any network traffic during the run. However one could just use independent non-GUI runs instead... > IMHO Danny > >> -----Ursprüngliche Nachricht----- >> Von: sebb [mailto:[email protected]] >> Gesendet: Sonntag, 18. August 2013 23:07 >> An: [email protected] >> Betreff: Re: About HoldSampleSender >> >> On 15 August 2013 22:02, Philippe Mouawad >> <[email protected]> wrote: >> > Hello, >> > Looking at this implementation, I wonder if it is really needed and >> > wether it should not be deprecated. >> > >> > It seems to me dangerous: >> > >> > - It requires a lot of memory, users should be aware of it. >> > - Even with lot of memory, it could impact highly performances of >> > jmeter-servers through GC impacts >> > >> > >> > Thoughts ? >> >> Yes, it's probably not very useful, but we should probably not delete it >> (yet). >> >> Let's add some docs to say don't use it (and perhaps add a log.warn >> message on startup). >> >> >> > -- >> > Regards. >> > Philippe M.
