jakarta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Philippe Mouawad <philippe.moua...@gmail.com>
Subject Re: [Bug 51919] Random ConcurrentModificationException or NoSuchElementException in CookieManager#removeMatchingCookies when using Concurrent Download
Date Sat, 01 Oct 2011 13:33:15 GMT
A little additional note,
There is an implementation of Concurrent map by doug lea in concurrent.jar
called ConcurrentReaderHashMap
that has same performance as HashMap in read and a little less on write.
But performances are much better than ConcurrentHashMap.
So maybe a better alternative but requires concurrent-1.3.4.jar from:

   -
   http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html



package org.apache.jmeter.protocol.http.control;

import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;

import org.apache.commons.lang.time.StopWatch;

import EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap;

public class TestMap {

    public static void main(String[] args) {
        StopWatch timer = new StopWatch();

        Map map = new HashMap();
        testPut(timer, map, "HashMap");
        timer.reset();

        map = new ConcurrentHashMap();
        testPut(timer, map, "ConcurrentHashMap");
        timer.reset();

        map = new ConcurrentReaderHashMap();
        testPut(timer, map, "ConcurrentReaderHashMap");
        timer.reset();


        map = new HashMap();
        testGet(timer, map, "HashMap");
        timer.reset();

        map = new ConcurrentHashMap();
        testGet(timer, map, "ConcurrentHashMap");
        timer.reset();

        map = new ConcurrentReaderHashMap();
        testGet(timer, map, "ConcurrentReaderHashMap");
        timer.reset();
    }

    /**
     * @param timer
     */
    private static void testGet(StopWatch timer, Map map, String type) {
        timer.start();
        for (int i = 0; i < 1000000; i++) {
            map.get(i);
        }
        timer.stop();
        System.out.println(type+" get:"+timer.getTime());
    }

    /**
     * @param timer
     */
    private static void testPut(StopWatch timer, Map map, String type) {
        timer.start();
        for (int i = 0; i < 1000000; i++) {
            map.put(i,i);
        }
        timer.stop();
        System.out.println(type+"put:"+timer.getTime());
    }

    /**
     * @param timer
     */
    private static void testGet(StopWatch timer, Map map) {
        timer.start();
        for (int i = 0; i < 1000000; i++) {
            map.get(i);
        }
        timer.stop();
        System.out.println("ConcurrentHashMap get:"+timer.getTime());
    }
}


On Sat, Oct 1, 2011 at 1:53 PM, sebb <sebbaz@gmail.com> wrote:

> On 1 October 2011 12:38, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > On Sat, Oct 1, 2011 at 12:57 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 1 October 2011 10:53, Philippe Mouawad <
> p.mouawad@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, <bugzilla@apache.org> wrote:
> >> >
> >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=51919
> >> >>
> >> >> --- Comment #2 from Milamber <milamber@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-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> > --
> > Cordialement.
> > Philippe Mouawad.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: dev-help@jakarta.apache.org
>
>


-- 
Cordialement.
Philippe Mouawad.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message