On 1 October 2011 12:38, Philippe Mouawad <philippe.moua...@gmail.com> wrote: > On Sat, Oct 1, 2011 at 12:57 PM, sebb <seb...@gmail.com> wrote: > >> On 1 October 2011 10:53, Philippe Mouawad <p.moua...@ubik-ingenierie.com> >> wrote: >> > Hello Milamber, Sebb, All, >> > Regarding 51919 < >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919>, >> > I wonder if there is not an issue in JMeterVariables access introduced by >> > concurrent download. >> > Initially I think JMeterVariables were not supposed to be shared so >> object >> > not thread safe, today they are due to Conc download. >> > Maybe JMeterVariables#variables should be replaced by a >> ConcurrentHashMap. >> > If so CONTEXT_VARIABLES_LOCK should be removed in my patch. >> > What do you think? >> >> Yes, a lot of JMeter code assumes that samplers and thread variables >> are not shared. >> >> So either we remove those assumptions, which might prove more >> expensive in the non-concurrent case; > > > => Performance impact is around 3 times more between ConcurrentHashMap and > HashMap > when only one thread is using Map (ie case when no concurrent downloads > occur) but maybe > it is not that important regarding other parts of code, needs some study.
Indeed, study is needed. > >> or we change the way the >> concurrent downloads are handled so they don't directly access the >> main thread variables. >> >> => Don't you think code will be hard to maintain ? today AsyncSampler uses > same sample() method as others That is presumably broken as well, then. > won't there be lot of special cases ? > Potentially yes, but the alternative is to revisit and potentially rewrite large chunks of JMeter code. That needs a proper strategy first, as well as loads of tests to check the behaviour. >> One way might be to clone the sampler so it effectively becomes a new >> JMeterThread; I don't know how easy that would be, we would also need >> to recover the updates at the end of the sub-samples. >> >> Another way would be to intercept the writes to the objects that are >> not thread-safe and store them up for the main sample thread to do at >> the end. >> >> Either way, at present the concurrent downloads unfortunately have >> problems with cookie handling (and with buffer handling, but that is >> trivial to fix). >> >> So a short-term approach might be to ignore cookies when performing >> sub-samples - I think it is only the cookies that require updates to >> the thread variables. >> >> Are there any use-cases where the web application relies on cookies >> that are set by resources embedded in the main page? >> I know some sites set cookies on embedded resources, but is that >> necessary, or is it a by-product? >> > > => I agree, I have never met this case in my load tests but if it is met > load testing application will be hard > >> >> If not, then ignoring such cookies would be a long-term solution. >> >> > Regards >> > Philippe >> > >> > >> > On Sat, Oct 1, 2011 at 9:34 AM, <bugzi...@apache.org> wrote: >> > >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919 >> >> >> >> --- Comment #2 from Milamber <milam...@apache.org> 2011-10-01 07:34:04 >> UTC >> >> --- >> >> A better way is to synchronize only the code section referred to the >> >> variables >> >> from JMeterContext >> >> (in add() and removeMatchingCookies() methods, I thinks) >> >> >> >> -- >> >> Configure bugmail: >> >> https://issues.apache.org/bugzilla/userprefs.cgi?tab=email >> >> ------- You are receiving this mail because: ------- >> >> You are on the CC list for the bug. >> >> You reported the bug. >> >> >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> > Ubik-Ingénierie >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> > > > -- > Cordialement. > Philippe Mouawad. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
