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>
>> > Hello Milamber, Sebb, All,
>> > Regarding 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
>> > not thread safe, today they are due to Conc download.
>> > Maybe JMeterVariables#variables should be replaced by a
>> > 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
> 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
>> 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
>> >> ---
>> >> 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
> Philippe Mouawad.
To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org
For additional commands, e-mail: dev-h...@jakarta.apache.org