Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Some tests fail randomly (hard to reproduce). It appears to me that this is caused by uninitialized date fields. For example Uwe reported a failure today in this test of TestQueryParser:

       /** for testing legacy DateField support */
        public void testLegacyDateRange() throws Exception {
          String startDate = getLocalizedDate(2002, 1, 1, false);
          String endDate = getLocalizedDate(2002, 1, 4, false);
      

      if you look at the helper getLocalizedDate, you can see if the 4th argument is false, it does not initialize all date field functions.

        private String getLocalizedDate(int year, int month, int day, boolean extendLastDate) {
       Calendar calendar = new GregorianCalendar();
       calendar.set(year, month, day);
       if (extendLastDate) {
            calendar.set(Calendar.HOUR_OF_DAY, 23);
            calendar.set(Calendar.MINUTE, 59);
            calendar.set(Calendar.SECOND, 59);
       ...
      }
      

      I think the solution to this is that in all tests, whereever we create new GregorianCalendar(), it should be followed by a call to Calendar.clear().
      This will ensure that we always initialize unused calendar fields to zero, rather than being dependent on the local time.

        Activity

        Hide
        Robert Muir added a comment -

        attached is a patch that not only clears all Calendar attributes to erase anything dependent on local time, but also ensures the same hour/minute/second/millisecond is used for actual and expected.

        This is because the date in the test (2002/1/4) becomes two different Thai dates, depending upon the hour of day, timezone, etc.

        The expected end date was always 4/2/2545, because these were set. But the actual end date would sometimes be 3/2/2545, depending upon when and where you ran the tests.

        Show
        Robert Muir added a comment - attached is a patch that not only clears all Calendar attributes to erase anything dependent on local time, but also ensures the same hour/minute/second/millisecond is used for actual and expected. This is because the date in the test (2002/1/4) becomes two different Thai dates, depending upon the hour of day, timezone, etc. The expected end date was always 4/2/2545, because these were set. But the actual end date would sometimes be 3/2/2545, depending upon when and where you ran the tests.
        Hide
        Robert Muir added a comment -

        Committed revision 890407.

        This may not be the complete solution, but its at least an improvement. I still do not trust these tests are doing exactly what we think...

        Show
        Robert Muir added a comment - Committed revision 890407. This may not be the complete solution, but its at least an improvement. I still do not trust these tests are doing exactly what we think...

          People

          • Assignee:
            Robert Muir
            Reporter:
            Robert Muir
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development