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 Mon, 03 Oct 2011 14:39:50 GMT
On Mon, Oct 3, 2011 at 4:31 PM, sebb <sebbaz@gmail.com> wrote:

> On 3 October 2011 14:04, Philippe Mouawad <philippe.mouawad@gmail.com>
> wrote:
> > You are right,
> > Patch was just about quick fix before the more impacting fix.
> >
> > Here are my propositions regarding this more impacting fix:
> >
> >   - Add an option to make conc download use or not cookie, default value
> >   will be false.
> >   - In AsyncSampler make a Clone with current cookies of Parent
> >   CookieManager (the one that is calling Executor) and store it in
> ThreadLocal
> >   - Change HttpSamplerBase#getCookieManager to retrieve first in Thread
> >   Local then in instance
> >   - If option is true, when reading res in Future<HTTPSampleResult> loop,
> >   reinject cookies inside ParentCookie otherwise ignore them
>
> As I wrote earlier, I'm not sure it ever makes sense to handle cookies
> from embedded resources, so it would be simpler just to ignore them.
>
> I am not sure Frame couldn't be concerned by this case, so in my opinion it
should be a parameter not ignored by default.


> I'm looking at passing the current sampler to the AsyncSampler class,
> which can then clone it.
> I think that will create an independent set of cookies, so there can
> be no need to protect against concurrent updates.
>
Agree, that's how I imagined it, but then you agree you have to store
CookieManager in thread local ?

>
> We then need to consider if non-concurrent downloads should still be
> processed for cookies.
>
>
Conc and serial should have the same behaviour


PS : Does it mean that you are working on issue and will fix it on your side
?

>
> > Regards
> > Philippe
> >
> > On Mon, Oct 3, 2011 at 2:29 PM, sebb <sebbaz@gmail.com> wrote:
> >
> >> On 3 October 2011 13:14, Philippe Mouawad <philippe.mouawad@gmail.com>
> >> wrote:
> >> > Sebb,
> >> > Do you want me to provide a patch with ConcurrentHashMap where I will
> >> have
> >> > to handle null keys and values (not same behaviour as HashMap) or we
> >> forget
> >> > about this approach ?
> >>
> >> I don't think we have yet decided how best to handle concurrent
> downloads.
> >>
> >> e.g. should they even be setting cookies?
> >>
> >> > Regards
> >> > Philippe
> >> >
> >> > On Mon, Oct 3, 2011 at 1:58 PM, Philippe Mouawad <
> >> philippe.mouawad@gmail.com
> >> >> wrote:
> >> >
> >> >> Hello,
> >> >> Just a little update on my test.
> >> >> I added a clear and gc before each Map instanciation and results are
> >> >> different:
> >> >>
> >> >>    - HashMapput:645
> >> >>    - ConcurrentHashMapput:832
> >> >>    - ConcurrentReaderHashMapput:620
> >> >>    - HashMap get:17
> >> >>    - ConcurrentHashMap get:32
> >> >>    - ConcurrentReaderHashMap get:60
> >> >>
> >> >>
> >> >> So it kind of closes the debate, sorry for disturbance.
> >> >> Regards
> >> >> Philippe
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> public class TestMap {
> >> >>
> >> >>     public static void main(String[] args) {
> >> >>         StopWatch timer = new StopWatch();
> >> >>
> >> >>         Map map = new HashMap();
> >> >>         testPut(timer, map, "HashMap");
> >> >>         timer.reset();
> >> >>
> >> >>         map.clear();
> >> >>         System.gc();
> >> >>
> >> >>         map = new ConcurrentHashMap();
> >> >>         testPut(timer, map, "ConcurrentHashMap");
> >> >>         timer.reset();
> >> >>
> >> >>         map.clear();
> >> >>         System.gc();
> >> >>
> >> >>         map = new ConcurrentReaderHashMap();
> >> >>         testPut(timer, map, "ConcurrentReaderHashMap");
> >> >>         timer.reset();
> >> >>
> >> >>
> >> >>         map.clear();
> >> >>         System.gc();
> >> >>
> >> >>         map = new HashMap();
> >> >>         testGet(timer, map, "HashMap");
> >> >>         timer.reset();
> >> >>
> >> >>         map.clear();
> >> >>         System.gc();
> >> >>
> >> >>         map = new ConcurrentHashMap();
> >> >>         testGet(timer, map, "ConcurrentHashMap");
> >> >>         timer.reset();
> >> >>
> >> >>         map.clear();
> >> >>         System.gc();
> >> >>
> >> >>         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());
> >> >>     }
> >> >>
> >> >>
> >> >> Regards
> >> >> Philippe
> >> >>
> >> >>
> >> >> On Mon, Oct 3, 2011 at 1:37 PM, sebb <sebbaz@gmail.com> wrote:
> >> >>
> >> >>> On 3 October 2011 12:15, Rainer Jung <rainer.jung@kippdata.de>
> wrote:
> >> >>> > On 02.10.2011 23:17, Philippe Mouawad wrote:
> >> >>> >> Ok, hope we can do the same.
> >> >>> >
> >> >>> > See https://issues.apache.org/jira/browse/XMLBEANS-447
> >> >>> >
> >> >>> > We are not the only people, who doubt it's correct to include
that
> >> class
> >> >>> ...
> >> >>> >
> >> >>> > There was also a discussion some time ago in another ASF project,
> >> >>> > because the Sun license which is cited by Doug Lea has a "no
use
> in
> >> >>> > nuclear facilities clause", which make it non-usable as an
Open
> >> Source
> >> >>> > license.
> >> >>> >
> >> >>> > It looks like we are stuck here.
> >> >>>
> >> >>> Yes, apart from the binary option which brings in lots of unneeded
> >> code.
> >> >>>
> >> >>> > And the mentioning of the Harmony class in the above cited
issue
> is a
> >> >>> > red herring. Diffing it with the JDK 5 standard ConcurrentHashMap
> >> shows
> >> >>> > little difference, so I doubt it will be much faster (though
I
> didn't
> >> >>> > inspect the delta in detail).
> >> >>>
> >> >>> I think the Harmony class was only mentioned as a means of
> supporting
> >> >>> Java 1.4, not as an alternative faster implementation.
> >> >>>
> >> >>> >> I must say I don't understand why ConcurrentReaderHashMap
is not
> in
> >> >>> JDK.
> >> >>> >
> >> >>> > There's a discussion list for JSR166 (the concurrency stuff
lead
> by
> >> Doug
> >> >>> > Lea) mentioned on the JSR 166 page maintained by Doug Lea.
So
> maybe
> >> you
> >> >>> > can post a technical question there (what's the right class
that
> >> solve
> >> >>> > the following problem ... and doesn't have sun licensing
> >> restrictions).
> >> >>> >
> >> >>> > Regards,
> >> >>> >
> >> >>> > Rainer
> >> >>> >
> >> >>> >
> >> >>> >
> ---------------------------------------------------------------------
> >> >>> > To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> >> >>> > For additional commands, e-mail: dev-help@jakarta.apache.org
> >> >>> >
> >> >>> >
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@jakarta.apache.org
> >> >>> For additional commands, e-mail: dev-help@jakarta.apache.org
> >> >>>
> >> >>>
> >> >>
> >> >>
> >> >> --
> >> >> Cordialement.
> >> >> Philippe Mouawad.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > 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.
> >
>
> ---------------------------------------------------------------------
> 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