Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B813C5D.43AAC12@apache.org>
Date: Mon, 20 Aug 2001 12:35:41 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [C2] sitemap creation threading issue ?
References: <78498F558F94D41194BB0000F80209DFBABBF6@moab.ncube.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael McKibben wrote:
> 
> I briefly glanced at the patch and one thing you can do to optimize the
> syncronization is to apply the "double check" lock pattern. This will allow
> you to remove the synchronized keyword from the method.  For example:


Warning!!!  I just read an article about the Double Check Lock Pattern.  There
are actually several sources that advise strongly against this!  I concur.  Try
using the Avalon Lock and/or Mutex objects.  They will allow you to safely remove
the synchronized methods while allowing you to safely order threads.

This makes things alot more stable and predictable.  Remember you may be able to
fool some of the JVMs some of the time, but you can't fool all the JVMs all the
time.

If you want to find out more, check out your favorite Java developer's mag, and
perform a search on Double Check Locking  (JavaWorld has a couple).

The issues lie in the Java memory model.

> 
> Handler sitemapHandler = (Handler)sitemaps.get(source);
> if (sitemapHandler != null) {
> ...
> }
> 
> Remove synchronized from the method and change body to:
> 
> Handler sitemapHandler = (Handler)sitemaps.get(source);
> if (sitemapHandler == null) {
>         synchronized (sitemaps) {
>                 sitemapHandler = (Handler)sitemaps.get(source);
>                 if (sitemapHandler == null) {
>                         // create handler, put in the Map ...
>                         sitemaps.put(...)
>                 }
>         }
> }
> 
> Notice that threads only get synchronized in the case where a new handler
> has not yet been created, not every call into the method!
> 
> Regards,
> 
> --mike
> 
> -----Original Message-----
> From: Morrison, John [mailto:John.Morrison@uk.experian.com]
> Sent: Monday, August 20, 2001 5:47 AM
> To: 'cocoon-dev@xml.apache.org'
> Subject: RE: [C2] sitemap creation threading issue ?
> 
> Hi all, esp Marcus,
> 
> I too have been running Load tests, I also noticed that 'something' was
> happening regularly to slow the response.  I hadn't gotten round to checking
> the code though (the testing machines are isolated - 0 access from/to my dev
> station).
> 
> I saw your patch and rejoiced ;) but it's taken the response of some of my
> pages from a couple of hundred milliseconds to over 5!  I've not yet looked
> at _what_ your patch did, but have you seen a similar increase in time?
> 
> J.
> 
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> > Sent: Monday, 20 August 2001 7:57 am
> > To: cocoon-dev@xml.apache.org
> > Subject: AW: [C2] sitemap creation threading issue ?
> >
> >
> > Hi Marcus,
> >
> > thanks for your patch. I applied it, please cross check :-)
> >
> > Carsten
> >
> > > -----Ursprungliche Nachricht-----
> > > Von: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> > > Gesendet: Samstag, 18. August 2001 22:41
> > > An: Cocoon Developers Mailing List
> > > Betreff: [C2] sitemap creation threading issue ?
> > >
> > >
> > > Hi *,
> > >
> > >     Hope all is well.
> > >
> > >     Michael and I have spent the day testing our C2 application with
> > >     LoadRunner and have potentially uncovered a threading
> > problem during
> > >     sitemap creation.
> > >
> > >     We're not experts with the code but from our understanding the
> > >     following is happening, please let us know if we are
> > right/wrong:
> > >
> > >     There seems to be a problem with the getHandler()
> > method, located in
> > >     the sitemap Manager class (line 154). getHandler() attempts
> > > to access a
> > >     sitemap handler object for each request for processing. If
> > > the handler
> > >     object is not available it creates one, causing the
> > sitemap to be
> > >     generated.
> > >
> > >     We've noticed under load, that many handler objects are
> > created for
> > >     the same sitemap. This is because getHandler() does not
> > protect the
> > >     following lines:
> > >
> > >             Handler sitemapHandler = (Handler)sitemaps.get(source);
> > >
> > >     and
> > >
> > >             sitemaps.put(source, sitemapHandler);
> > >
> > >     as a critical area.
> > >
> > >     If multiple concurrent threads pass through
> > getHandler() which are
> > >     requests for resources from the same sitemap, the first line
> > >     above will return null multiple times causing the same
> > sitemap to be
> > >     compiled several times, each by individual Handler objects.
> > >
> > >     This happens because sitemaps.put() executes after each
> > > sitemap handler
> > >     object is created (which can take time for large sitemaps),
> > > and cannot
> > >     prevent other incoming threads from waiting until it
> > adds the newly
> > >     created handler object into the 'sitemaps' hashmap.
> > >
> > >     When we synchronized the getHandler method to protect the
> > >     getting/setting of the sitemaps hashmap, we saw that the sitemap
> > >     handler object was created only once, and that the application
> > >     performed much better under load. Previously the same
> > > sitemap handler
> > >     object was created as many times as we had simultaneous threads
> > >     make requests.
> > >
> > >     Attached is a diff of the change we made. There might
> > be a better
> > >     solution as the Handler class seems to be built to
> > handle this, it's
> > >     just that the allocation of a new Handler objects per
> > > sitemap, defeats
> > >     it's internal multi-thread logic.
> > >
> > >     Any comments/thoughts/suggestions ?
> > >
> > >     Cheers,
> > >
> > >     Marcus
> > >
> > > --
> > >         .....
> > >      ,,$$$$$$$$$,      Marcus Crafter
> > >     ;$'      '$$$$:    Computer Systems Engineer
> > >     $:         $$$$:   Open Software Associates GmbH
> > >      $       o_)$$$:   82-84 Mainzer Landstrasse
> > >      ;$,    _/\ &&:'   60327 Frankfurt Germany
> > >        '     /( &&&
> > >            \_&&&&'     Email : Marcus.Crafter@osa.de
> > >           &&&&.        Business Hours : +49 69 9757 200
> > >     &&&&&&&:
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> 
> =======================================================================
> Information in this email and any attachments are confidential, and may
> not be copied or used by anyone other than the addressee, nor disclosed
> to any third party without our permission.  There is no intention to
> create any legally binding contract or other commitment through the use
> of this email.
> 
> Experian Limited (registration number 653331).
> Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org