Re: MultithreadedHttpConnectionManager and high loads
On Tue, 2008-10-28 at 23:51 +, sebb wrote: On 28/10/2008, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote: --- On Mon, 10/27/08, sebb [EMAIL PROTECTED] wrote: From: sebb [EMAIL PROTECTED] Subject: Re: MultithreadedHttpConnectionManager and high loads To: HttpClient User Discussion httpclient-users@hc.apache.org Date: Monday, October 27, 2008, 12:03 PM On 27/10/2008, De Groot, Cees [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultithreadedHttpConnectionManager and high loads
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- dagdag is just a two character rotation of byebye www.christine.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultithreadedHttpConnectionManager and high loads
--- On Mon, 10/27/08, sebb [EMAIL PROTECTED] wrote: From: sebb [EMAIL PROTECTED] Subject: Re: MultithreadedHttpConnectionManager and high loads To: HttpClient User Discussion httpclient-users@hc.apache.org Date: Monday, October 27, 2008, 12:03 PM On 27/10/2008, De Groot, Cees [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultithreadedHttpConnectionManager and high loads
On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote: --- On Mon, 10/27/08, sebb [EMAIL PROTECTED] wrote: From: sebb [EMAIL PROTECTED] Subject: Re: MultithreadedHttpConnectionManager and high loads To: HttpClient User Discussion httpclient-users@hc.apache.org Date: Monday, October 27, 2008, 12:03 PM On 27/10/2008, De Groot, Cees [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultithreadedHttpConnectionManager and high loads
On 28/10/2008, Oleg Kalnichevski [EMAIL PROTECTED] wrote: On Tue, 2008-10-28 at 09:19 -0700, Tatu Saloranta wrote: --- On Mon, 10/27/08, sebb [EMAIL PROTECTED] wrote: From: sebb [EMAIL PROTECTED] Subject: Re: MultithreadedHttpConnectionManager and high loads To: HttpClient User Discussion httpclient-users@hc.apache.org Date: Monday, October 27, 2008, 12:03 PM On 27/10/2008, De Groot, Cees [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MultithreadedHttpConnectionManager and high loads
On 27/10/2008, De Groot, Cees [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
