Hi!
Some weeks ago, I've written about a curiously Very Bad bug which basically
caused to client to reconnect so fast to the server, that it would die from
resource exhaustion. I've managed to get an idea of what's going on, and I
found where the "XmlBlaster.PingTimer" threads originate from.
Global.java:
public final Timeout getPingTimer() {
if (this.pingTimer == null) {
synchronized(this) {
if (this.pingTimer == null)
this.pingTimer = new Timeout("XmlBlaster.PingTimer");
}
}
return this.pingTimer;
}
And there, I realized how bad it is, because the double-checked-locking
idiom is _broken_:
http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html
It basically could create any number of theads! (Which, I think, happened
for me.)
To be more exact, this type of code can be fixed to run correctly on
1.5+Sun JVM by declaring the lazily constructed variables volatile.
However, it
is not implemented on 1.4 (see article), so users of that JVM would still be
able to experience a number of interesting things popping up very rarely on
their SMP machines.
So, it's particularly bad on SMP machines, which I happen to run the client
on.
To make things more interesting, there are at least 15 variables initialized
this way in Global.java. I haven't looked anywhere else.
As I have said, it can be fixed by declaring these fields volatile on JVMs I
use, but that would mean no solution to some other users.
regards,
Balázs Póka
