Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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; or we change the way the concurrent downloads are handled so they don't directly access the main thread variables. 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? 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
Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
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
Re: JMeter TLP - draft resolution and first chair
On Wed, Sep 21, 2011 at 8:31 PM, sebb seb...@gmail.com wrote: On 22 September 2011 01:15, Rahul Akolkar rahul.akol...@gmail.com wrote: On Wed, Sep 21, 2011 at 7:33 PM, Henri Yandell bay...@generationjava.com wrote: On Thu, Sep 22, 2011 at 1:30 AM, Rahul Akolkar rahul.akol...@gmail.com wrote: On Tue, Sep 20, 2011 at 3:15 AM, Henri Yandell bay...@generationjava.com wrote: Happy to be on the PMC :) I'm not sure I'll be that active, but hopefully can help with any setup items. +1 for Sebb as Chair. I've updated the resolution to reflect the nomination. If there are no further changes to the proposal in a couple of days, I'll start the TLP vote. We shouldn't vote until Sebb, or someone else, is signed up to be the chair. snip/ Thats reasonable too :-) Sebb? I would have preferred to see JMeter as part of HC, but perhaps it would be better as a TLP. snip/ IMO, yes. However I think we need some more PMC members first. snap/ I see you added olegk, which is goodness. We can always add others later. I think we're good for a vote on the resolution as is on the wiki. WDYT? -Rahul I can think of some Jakarta PMC members who have been involved with JMeter recently, and I think some of the Tomcat PMC use JMeter. Is it OK just to add them, or should they be asked first? - To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
