cburroughs
commented
7 years ago I am deeply regretting not saving the full stack trace, because this is much more confusing than I thought:
- I would have thought that the signature cache would make this absurdly unlikely, but I suppose in this case the problem is calculating the cache key and not value
- In practice (use by java-manta) I thought Singers were ThreadLocal.... but
DATE_FORMATis static - Access to
TimeZone.getTimeZoneis syncronized... but while that is on the same line it is not the same statement.
I've been unable to reproduce this exact case synthetically. A snippet will help explain:
public static void main(String args[]) throws Exception {
TestApp app = new TestApp();
app.setup();
app.run();
}
public void run() throws Exception {
for (int i =0; i< 48 ; i++){
Thread thread = new Thread(new Runner());
thread.start();
}
}
public class Runner implements Runnable {
public void run() {
String str;
String str2;
for (long i=1; ; i++) {
str = signer.defaultSignDateAsString();
//str2 = signer.DATE_FORMAT.format(new java.util.Date(i));
}
}
} No amount of fiddling with signer.defaultSignDateAsString() and the number of threads has reproduced this, but formatting two different dates quickly errors (the str2 statement). Since we are always formatting "now", I think the reason we don't see this all the time in practice is that threads usually agree on what time it is and only on the "border" of time units could we hit this.
That makes me feel slightly less crazy as with many instances running 24/7 I think I've only seen this once. Still need to fix as it is a bug and we are grabbing a lock we do not need. It would just be nice to have a cleaner repro case.
Example from a concurrency heavy test:
See https://bugs.openjdk.java.net/browse/JDK-6231579 --> from the docs "Date formats are not synchronized"