I straightened out a number of startup deadlock issues for 5.2. They can
be very challenging to root out.
On Thu, Jun 14, 2012 at 9:47 PM, Jens Breitenstein TOC <
jens.breitenst...@t-o-c.biz> wrote:
> Hi Howard,
>
> In the past we had severe problems with T5 when a tomcat was started under
> hea
Hi Howard,
In the past we had severe problems with T5 when a tomcat was started under
heavy load. It deadlocked reproduceble in the classloader / bytecode
instrumentation area. Thus we workaround this issue but clicking the index page
manually ones before adding the tomcat to the loadbalancer (
Right, I should known that it will not lock when there are some readers.
Denis
Jun 14, 2012 v 7:28 PM, Howard Lewis Ship:
> I'm already somewhat unhappy at the complexity of the code; I'd prefer not
> to make it any more complicated. I think race conditions on the write lock
> are going to be p
I'm already somewhat unhappy at the complexity of the code; I'd prefer not
to make it any more complicated. I think race conditions on the write lock
are going to be pretty rare and probably only occur on a somewhat saturated
server at initial startup. I think twisting the code ever further.
In
Concurrency topic:
Would it be possible to change the lazy init to check if write lock is already
locked? It will eliminate the posibility of locking the write lock by more then
one thread.
try {
readLock.lock();
if(is need to init)
{
boolean hasWriteLock = false;
try {
Could be https://issues.apache.org/jira/browse/TAP5-1873 fixed? There is a
missing parameter in a call and improved exception logging.
Thanks,
Denis
Jun 11, 2012 v 8:36 PM, Howard Lewis Ship:
> On Wed, Jun 6, 2012 at 5:37 PM, Cezary Biernacki wrote:
>> On Thu, Jun 7, 2012 at 1:27 AM, H
On Wed, Jun 6, 2012 at 5:37 PM, Cezary Biernacki wrote:
> On Thu, Jun 7, 2012 at 1:27 AM, Howard Lewis Ship wrote:
>
>> You can even omit synchronized and volatile IFF:
>> - only a single shared field is updated
>> - it is ok for a race condition to exist that would create the value
>> on multipl
Thanks for the feedback!
On Mon, Jun 11, 2012 at 10:58 AM, Christian Riedel
wrote:
> Testing Tapestry 5.3.4-rc-5 and now Tapestry 5.3.4-rc-6 without any problems!
> Site looks good, page response times dropped a bit but we don't have
> thousands of concurrent users… yet
Testing Tapestry 5.3.4-rc-5 and now Tapestry 5.3.4-rc-6 without any problems!
Site looks good, page response times dropped a bit but we don't have thousands
of concurrent users… yet! ;-)
Am 06.06.2012 um 19:32 schrieb Howard Lewis Ship:
> For those that are interested, I just commit
On Thu, Jun 7, 2012 at 3:26 AM, Martin Strand <
do.not.eat.yellow.s...@gmail.com> wrote:
> On Thu, 07 Jun 2012 02:24:35 +0200, Cezary Biernacki
> wrote:
>
> "* The semantics of volatile variables have been strengthened to have
>> acquire and release semantics. In the original specification, acces
On Thu, 07 Jun 2012 02:24:35 +0200, Cezary Biernacki
wrote:
"* The semantics of volatile variables have been strengthened to have
acquire and release semantics. In the original specification, accesses to
volatile and non-volatile variables could be
freely ordered.
Aha, so does this mean that
On Thu, Jun 7, 2012 at 1:27 AM, Howard Lewis Ship wrote:
> You can even omit synchronized and volatile IFF:
> - only a single shared field is updated
> - it is ok for a race condition to exist that would create the value
> on multiple threads
> - (I learned this by getting schooled on the subject
>
> If I'm not mistaken, JSR-133 only affects final fields so we still have
> the same problem for non-final fields.
> i.e any non-final fields in Messages might still be uninitialized even if
> the *reference* is visible to other threads (messages != null)
>
>
Actually, JSR-133 guarantees that fi
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
> On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
>>
>>
>> http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
>
> I am curious is there a reason to not use 'double-checked locking' pattern?
> I know that it
On Wed, 06 Jun 2012 23:29:52 +0200, Kalle Korhonen
wrote:
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
I am curious is there a reason to not use
On Wed, Jun 6, 2012 at 1:51 PM, Cezary Biernacki wrote:
> On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
>> http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
> I am curious is there a reason to not use 'double-checked locking' pattern?
> I know that it was bro
On 06 June 2012 21:20:02 +0200 Howard Lewis Ship wrote:
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
I am curious is there a reason to not use 'double-checked locking' pattern? I
know that it was broken in Java 1.4 and earlier, but Java Memory Model was
change
http://tapestryjava.blogspot.com/2012/06/synchronized-considered-harmful.html
Like everything else that's good in Tapestry: no magic bullet, just
discipline and determination.
On Wed, Jun 6, 2012 at 10:52 AM, Thiago H de Paula Figueiredo
wrote:
> On Wed, 06 Jun 2012 14:32:02 -0300, Howard Lewis
On Wed, 06 Jun 2012 14:32:02 -0300, Howard Lewis Ship
wrote:
For those that are interested, I just committed some further speed
boosts to Tapestry, and generated a new preview release.
The client who I'm doing this for saw the throughput on their load
test go from 450 req/sec to 2000 req/sec
For those that are interested, I just committed some further speed
boosts to Tapestry, and generated a new preview release.
The client who I'm doing this for saw the throughput on their load
test go from 450 req/sec to 2000 req/sec ... what will your
application see?
--
Howard M. Lewis Ship
Cre
20 matches
Mail list logo
