You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by "De Groot, Cees" <cd...@marktplaats.nl> on 2008/10/27 16:29:46 UTC
MultithreadedHttpConnectionManager and high loads
Hi,
We're using HC in order to access an internal high-volume service
(thousands reqs/sec), and we noticed that DefaultHttpParams is
synchronized all over the place. This kills concurrency (I have a thread
dump showing ~1200 threads waiting there ;-)), and I don't think it is
necessary - it should be possible to read settings without having to
acquire locks first.
We found some references to this issue on the Net, but none on this
mailing list. Is this a known issue? Is this something that needs
fixing?
Thanks,
Cees de Groot
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by Christine <ch...@christine.nl>.
On Mon, 2008-10-27 at 08:29 -0700, De Groot, Cees wrote:
> Hi,
>
> We're using HC in order to access an internal high-volume service
> (thousands reqs/sec), and we noticed that DefaultHttpParams is
> synchronized all over the place. This kills concurrency (I have a thread
> dump showing ~1200 threads waiting there ;-)),
Do you mean that you have a number of threads reading from the same
source? What exactly do you mean by "all over the place"?
dagdag
Christine
> and I don't think it is
> necessary - it should be possible to read settings without having to
> acquire locks first.
>
> We found some references to this issue on the Net, but none on this
> mailing list. Is this a known issue? Is this something that needs
> fixing?
>
> Thanks,
>
> Cees de Groot
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
--
dagdag is just a two character rotation of byebye
www.christine.nl
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2008-10-28 at 23:51 +0000, sebb wrote:
> On 28/10/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote:
> > > --- On Mon, 10/27/08, sebb <se...@gmail.com> wrote:
> > >
> > > > From: sebb <se...@gmail.com>
> > > > Subject: Re: MultithreadedHttpConnectionManager and high loads
> > > > To: "HttpClient User Discussion" <ht...@hc.apache.org>
> > > > Date: Monday, October 27, 2008, 12:03 PM
> > > > On 27/10/2008, De Groot, Cees
> > > > <cd...@marktplaats.nl> wrote:
> > > > > Hi,
> > > > >
> > > > > We're using HC in order to access an internal
> > > > high-volume service
> > > > > (thousands reqs/sec), and we noticed that
> > > > DefaultHttpParams is
> > > > > synchronized all over the place. This kills
> > > > concurrency (I have a thread
> > > > > dump showing ~1200 threads waiting there ;-)), and I
> > > > don't think it is
> > > > > necessary - it should be possible to read settings
> > > > without having to
> > > > > acquire locks first.
> > > >
> > > > That's not necessarily true. Synchronize does more than
> > > > provide mutual exclusion - i.e. locking - it also ensures that fields
> > > > written in one thread are correctly seen in another.
> > >
> > > This is certainly correct and good point (details of how the memory view syncing is done can be even more complicated than simple flush, conceptually it's a memory barrier). For anyone unfamiliar with the concept (mutex and memory consistency) should read "Java Memory Model" article:
> > >
> > > http://www.cs.umd.edu/~pugh/java/memoryModel/
> > >
> > > Anyway, one thing I was wondering was whether syncs (or, the alternative, using volatile) could still be avoided for default values.
> > > This because it would seem like such values would be immutable?
> > >
> >
> >
> > This is indeed the case. HttpParams are used in write once / ready many
> > mode and therefore its methods do not necessarily need to be
> > synchronized to be threading safe.
>
> As far as I know this is not the case unless the variable is final,
> volatile, or set up during class initialisation. Otherwise, the JVM is
> free to cache the written or previously read value.
>
> Whether it does so is another matter; there's nothing to stop the the
> JVM from flushing the variable earlier. So unsafe code may still work.
>
> However, if the writer thread and reader thread(s) both synchronise on
> the same object then any variables that were set before the synch
> calls will be seen by the other thread - the variables don't have to
> set as part of the synch block. This is part of the "happens-before"
> rule, if I've understood it correctly.
>
While this is certainly true, it is very unlikely this can affect
HttpParams given the fact they are initialized when HttpClient instance
is created and then read from _much_ later in time (many, many CPU
cycles after) when requests are executed.
Oleg
> > HttpClient 4.0 uses unsynchronized implementation of HttpParams per
> > default
> >
> >
> > Oleg
> >
> >
> >
> > > -+ Tatu +-
> > >
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by sebb <se...@gmail.com>.
On 28/10/2008, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote:
> > --- On Mon, 10/27/08, sebb <se...@gmail.com> wrote:
> >
> > > From: sebb <se...@gmail.com>
> > > Subject: Re: MultithreadedHttpConnectionManager and high loads
> > > To: "HttpClient User Discussion" <ht...@hc.apache.org>
> > > Date: Monday, October 27, 2008, 12:03 PM
> > > On 27/10/2008, De Groot, Cees
> > > <cd...@marktplaats.nl> wrote:
> > > > Hi,
> > > >
> > > > We're using HC in order to access an internal
> > > high-volume service
> > > > (thousands reqs/sec), and we noticed that
> > > DefaultHttpParams is
> > > > synchronized all over the place. This kills
> > > concurrency (I have a thread
> > > > dump showing ~1200 threads waiting there ;-)), and I
> > > don't think it is
> > > > necessary - it should be possible to read settings
> > > without having to
> > > > acquire locks first.
> > >
> > > That's not necessarily true. Synchronize does more than
> > > provide mutual exclusion - i.e. locking - it also ensures that fields
> > > written in one thread are correctly seen in another.
> >
> > This is certainly correct and good point (details of how the memory view syncing is done can be even more complicated than simple flush, conceptually it's a memory barrier). For anyone unfamiliar with the concept (mutex and memory consistency) should read "Java Memory Model" article:
> >
> > http://www.cs.umd.edu/~pugh/java/memoryModel/
> >
> > Anyway, one thing I was wondering was whether syncs (or, the alternative, using volatile) could still be avoided for default values.
> > This because it would seem like such values would be immutable?
> >
>
>
> This is indeed the case. HttpParams are used in write once / ready many
> mode and therefore its methods do not necessarily need to be
> synchronized to be threading safe.
As far as I know this is not the case unless the variable is final,
volatile, or set up during class initialisation. Otherwise, the JVM is
free to cache the written or previously read value.
Whether it does so is another matter; there's nothing to stop the the
JVM from flushing the variable earlier. So unsafe code may still work.
However, if the writer thread and reader thread(s) both synchronise on
the same object then any variables that were set before the synch
calls will be seen by the other thread - the variables don't have to
set as part of the synch block. This is part of the "happens-before"
rule, if I've understood it correctly.
> HttpClient 4.0 uses unsynchronized implementation of HttpParams per
> default
>
>
> Oleg
>
>
>
> > -+ Tatu +-
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote:
> --- On Mon, 10/27/08, sebb <se...@gmail.com> wrote:
>
> > From: sebb <se...@gmail.com>
> > Subject: Re: MultithreadedHttpConnectionManager and high loads
> > To: "HttpClient User Discussion" <ht...@hc.apache.org>
> > Date: Monday, October 27, 2008, 12:03 PM
> > On 27/10/2008, De Groot, Cees
> > <cd...@marktplaats.nl> wrote:
> > > Hi,
> > >
> > > We're using HC in order to access an internal
> > high-volume service
> > > (thousands reqs/sec), and we noticed that
> > DefaultHttpParams is
> > > synchronized all over the place. This kills
> > concurrency (I have a thread
> > > dump showing ~1200 threads waiting there ;-)), and I
> > don't think it is
> > > necessary - it should be possible to read settings
> > without having to
> > > acquire locks first.
> >
> > That's not necessarily true. Synchronize does more than
> > provide mutual exclusion - i.e. locking - it also ensures that fields
> > written in one thread are correctly seen in another.
>
> This is certainly correct and good point (details of how the memory view syncing is done can be even more complicated than simple flush, conceptually it's a memory barrier). For anyone unfamiliar with the concept (mutex and memory consistency) should read "Java Memory Model" article:
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/
>
> Anyway, one thing I was wondering was whether syncs (or, the alternative, using volatile) could still be avoided for default values.
> This because it would seem like such values would be immutable?
>
This is indeed the case. HttpParams are used in write once / ready many
mode and therefore its methods do not necessarily need to be
synchronized to be threading safe.
HttpClient 4.0 uses unsynchronized implementation of HttpParams per
default
Oleg
> -+ Tatu +-
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by Tatu Saloranta <co...@yahoo.com>.
--- On Mon, 10/27/08, sebb <se...@gmail.com> wrote:
> From: sebb <se...@gmail.com>
> Subject: Re: MultithreadedHttpConnectionManager and high loads
> To: "HttpClient User Discussion" <ht...@hc.apache.org>
> Date: Monday, October 27, 2008, 12:03 PM
> On 27/10/2008, De Groot, Cees
> <cd...@marktplaats.nl> wrote:
> > Hi,
> >
> > We're using HC in order to access an internal
> high-volume service
> > (thousands reqs/sec), and we noticed that
> DefaultHttpParams is
> > synchronized all over the place. This kills
> concurrency (I have a thread
> > dump showing ~1200 threads waiting there ;-)), and I
> don't think it is
> > necessary - it should be possible to read settings
> without having to
> > acquire locks first.
>
> That's not necessarily true. Synchronize does more than
> provide mutual exclusion - i.e. locking - it also ensures that fields
> written in one thread are correctly seen in another.
This is certainly correct and good point (details of how the memory view syncing is done can be even more complicated than simple flush, conceptually it's a memory barrier). For anyone unfamiliar with the concept (mutex and memory consistency) should read "Java Memory Model" article:
http://www.cs.umd.edu/~pugh/java/memoryModel/
Anyway, one thing I was wondering was whether syncs (or, the alternative, using volatile) could still be avoided for default values.
This because it would seem like such values would be immutable?
-+ Tatu +-
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: MultithreadedHttpConnectionManager and high loads
Posted by sebb <se...@gmail.com>.
On 27/10/2008, De Groot, Cees <cd...@marktplaats.nl> wrote:
> Hi,
>
> We're using HC in order to access an internal high-volume service
> (thousands reqs/sec), and we noticed that DefaultHttpParams is
> synchronized all over the place. This kills concurrency (I have a thread
> dump showing ~1200 threads waiting there ;-)), and I don't think it is
> necessary - it should be possible to read settings without having to
> acquire locks first.
That's not necessarily true. Synchronize does more than provide mutual
exclusion - i.e. locking - it also ensures that fields written in one
thread are correctly seen in another.
Without synch. there is no guarantee that reader threads will see the
latest value written to a variable, as the JVM is free to cache
variables locally. The synch. forces a memory flush (for writers) and
memory refetch (for readers).
> We found some references to this issue on the Net, but none on this
> mailing list. Is this a known issue? Is this something that needs
> fixing?
>
> Thanks,
>
> Cees de Groot
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org