2011-01-14 10 views
0

Ich hoffe, folgende Erklärung wird Sinn machen, weil es ein seltsames Problem ist, das wir konfrontiert sind und schwer zu beschreiben.Gelegentlich Datum oder Zeitzone Diskrepanz in Hudson oder Maven mit jodatime

Wir haben ein Maven-Projekt, das in Hudson erstellt wird und das einige Komponententests enthält, in denen Datumsangaben verwendet und bestätigt werden. Der Hudson Server läuft auf Solaris. Nun, gelegentlich (wie 30% der Zeiten) scheitern die Komponententests mit Datumsangaben, da 3,5 Stunden von der spezifizierten Zeit in dem Komponententest abgezogen werden und somit einen Fehlstart bestätigen. Bei den anderen 70% funktioniert alles gut, obwohl sich im Code nichts geändert hat und wir den Hudson-Job mehrmals pro Stunde ausführen.

Ich füge folgenden Code in eine Unittest die Zeit zu überprüfen:

@Test 
public void testDate() { 
    System.out.println("new DateMidnight(2011, 1, 5).toDate();"); 
    System.out.println(new DateMidnight(2011, 1, 5).toDate()); 
    System.out.println(new DateMidnight(2011, 1, 5).toDate().getTime()); 

    Calendar cal = Calendar.getInstance(); 
    cal.set(Calendar.YEAR, 2011); 
    cal.set(Calendar.MONTH, 0); 
    cal.set(Calendar.DAY_OF_MONTH, 5); 
    cal.set(Calendar.HOUR, 0); 
    cal.set(Calendar.MINUTE, 0); 
    cal.set(Calendar.SECOND, 0); 
    cal.set(Calendar.MILLISECOND, 0); 
    System.out.println("cal.getTime();"); 
    System.out.println(cal.getTime()); 
    System.out.println(cal.getTime().getTime()); 
} 

Also im Grunde sollte es die gleiche Sache drucken, wenn jodatime oder plain old Kalender verwenden. Dies ist in 70% der Fälle der Fall; für die anderen 30% I Ausdrucke erhalten folgende:

Running TestSuite 
new DateMidnight(2011, 1, 5).toDate(); 
Tue Jan 04 21:30:00 MET 2011 
1294173000000 
cal.getTime(); 
Wed Jan 05 12:00:00 MET 2011 
1294225200000 

So Kalender hält das richtige Datum und die Uhrzeit, aber jodatime abzieht 3,5 Stunden.

Lokale Maven-Tests erscheinen nie die Pose dieses Problem und wir können nicht herausfinden, was könnte die Ursache dafür sein. Insbesondere können wir uns keinen einzigen Grund vorstellen, warum die Tests manchmal erfolgreich sind und manchmal fehlschlagen, ohne Code, Hudson oder Servereinstellungen zu ändern.

Auch führen wir die Maven-Installation mit Cobertura, was bedeutet, dass die Komponententests zweimal ausgeführt werden. Es passiert auch, dass sie das erste Mal passieren und beim zweiten Mal scheitern oder dass sie beide Male versagen.

Vielen Dank für alle Lösungen oder Tipps, um die Ursache aufzuspüren,
Stijn

Antwort

0

Das Problem scheint jetzt behoben zu sein.

Wir haben unsere jodatime Version von 5.14.2 auf 5.14.6 aktualisiert. Seitdem habe ich jede halbe Stunde den Build auf Auto ausgeführt, so dass wir nach etwa 100 Runs nie wieder auf dieses Problem gestoßen sind.

0

Vielleicht ist Hudson auf 3 Servern ausgeführt wird, und 1 hat eine andere Version der Zeitzonendaten in dem JDK von der anderen 2? (Überprüfen Sie die JVM-Version im Detail). Denken Sie daran, dass Joda-Time auch eine eigene Version der Zeitzonendaten hat, und die beiden können unterschiedlich sein.

1

Möglicherweise wird auch eine Version von SUREFIRE-533 gestartet, die durch Festlegen der TZ-Umgebungsvariablen in der Umgebung, in der Hudson ausgeführt wird, lösbar sein sollte. Bitte melden Sie das Problem, wenn dies hilft.