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
<http://www.cs.umd.edu/%7Epugh/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