glassfish
  1. glassfish
  2. GLASSFISH-19765

Zip distribution produced by continuous builds have files with future time stamp

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 4.0_b78
    • Fix Version/s: 4.0_b79
    • Component/s: build_system
    • Labels:
      None
    • Status Whiteboard:
      Hide

      Workaround:
      On Linux you can fix the timestamps like this:
      unzip -DD glassfish.zip
      On systems where -DD is not an option, use touch:
      find glassfish4 -exec touch {}\;

      Show
      Workaround: On Linux you can fix the timestamps like this: unzip -DD glassfish.zip On systems where -DD is not an option, use touch: find glassfish4 -exec touch {}\;

      Description

      I have been trying to understand why fighterfish job started to fail in unexpected way and what I have found is that one of the build machine's clock may not correctly set or there is something wrong with build. I just picked glassfish.zip from build #13576 [1] that was done in sc11152330.us.oracle.com at 5.30AM on March 1.

      http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/13576/artifact/bundles/glassfish.zip
      unzip glassfish.zip

      unzip -l glassfish.zip | grep glassfish.jar
      127784 03-01-2013 13:55 glassfish4/glassfish/modules/glassfish.jar

      stat glassfish4/glassfish/modules/glassfish.jar
      File: `glassfish4/glassfish/modules/glassfish.jar'
      Size: 127784 Blocks: 256 IO Block: 4096 regular file
      Device: ca02h/51714d Inode: 1324425 Links: 1
      Access: (0644/rw-rr-) Uid: (142213/sanjsaho) Gid: ( 10/ wheel)
      Access: 2013-03-01 13:55:58.000000000 -0800
      Modify: 2013-03-01 13:55:58.000000000 -0800
      Change: 2013-03-01 09:34:57.886099896 -0800

      Do you notice the file has a last modified timestamp of March 01@13:55:58 PST?

      Because this file has a timestamp in future, it is considered newer than some other files and that in turn causes my tests to fail. Is it a clock issue or some other build issue? What I also don't understand why the last change timestamp is different from the other timestamps by such a huge margin.

      Thanks,
      Sahoo

      [1] http://gf-hudson.us.oracle.com/hudson/job/gf-trunk-build-continuous/13576/

        Activity

        Hide
        Tom Mueller added a comment -

        This problem might be effecting the developer scenario performance benchmarks. See:
        http://hudson-sca.us.oracle.com/job/as-dev-benchmark-trunk-win/japex/ (internal link)

        When the test is run within hours of when the glassfish.zip was produced, then we get really long server startup times. When the test is run later with the same file, then the startup time is fine.

        Show
        Tom Mueller added a comment - This problem might be effecting the developer scenario performance benchmarks. See: http://hudson-sca.us.oracle.com/job/as-dev-benchmark-trunk-win/japex/ (internal link) When the test is run within hours of when the glassfish.zip was produced, then we get really long server startup times. When the test is run later with the same file, then the startup time is fine.
        Hide
        Jill Sato added a comment -

        The gf-trunk-build-continuous job recently was moved over to use the Oracle VM machines (POOL-1 machines).
        All the Oracle VMs set up by GIT have timezone TZ=UTC.
        Looks like the ant zip classes use the UTC timestamp to zip the classes (8 hrs ahead of Pacific Time).
        That's why the files look like they are "in the future."

        % cat /etc/default/init
        TZ=UTC
        CMASK=022
        LC_COLLATE=en_US.ISO8859-1
        LC_CTYPE=en_US.ISO8859-1
        LC_MESSAGES=C
        LC_MONETARY=en_US.ISO8859-1
        LC_NUMERIC=en_US.ISO8859-1
        LC_TIME=en_US.ISO8859-1

        And this symlink exists:
        /etc/TIMEZONE -> /etc/default/init

        However, TZ in my environment is set to PST8PDT when I'm on those VMs.
        % env | grep TZ
        TZ=PST8PDT

        and the 'date' command still says PST on that same machine.
        % date
        Monday, March 4, 2013 09:48:44 AM PST

        Show
        Jill Sato added a comment - The gf-trunk-build-continuous job recently was moved over to use the Oracle VM machines (POOL-1 machines). All the Oracle VMs set up by GIT have timezone TZ=UTC. Looks like the ant zip classes use the UTC timestamp to zip the classes (8 hrs ahead of Pacific Time). That's why the files look like they are "in the future." % cat /etc/default/init TZ=UTC CMASK=022 LC_COLLATE=en_US.ISO8859-1 LC_CTYPE=en_US.ISO8859-1 LC_MESSAGES=C LC_MONETARY=en_US.ISO8859-1 LC_NUMERIC=en_US.ISO8859-1 LC_TIME=en_US.ISO8859-1 And this symlink exists: /etc/TIMEZONE -> /etc/default/init However, TZ in my environment is set to PST8PDT when I'm on those VMs. % env | grep TZ TZ=PST8PDT and the 'date' command still says PST on that same machine. % date Monday, March 4, 2013 09:48:44 AM PST
        Hide
        Jill Sato added a comment -

        ok, changed TZ value in /etc/default/init and doing another build on gf-trunk-build-continuous.
        Will see if that fixes it...

        TZ=US/Pacific

        Show
        Jill Sato added a comment - ok, changed TZ value in /etc/default/init and doing another build on gf-trunk-build-continuous. Will see if that fixes it... TZ=US/Pacific
        Hide
        Tom Mueller added a comment -

        While the Felix optimizations can certainly depend on the system time being later than the timestamp of every file, it seems that it should be able to deal with future timestamps in a graceful way. The server should not hang or crash just because there is a future timestamp.

        After the build problem is fixed, it seems that there should still be new issue filed for Felix (or whereever this problem is) that addresses the stability issue.

        Show
        Tom Mueller added a comment - While the Felix optimizations can certainly depend on the system time being later than the timestamp of every file, it seems that it should be able to deal with future timestamps in a graceful way. The server should not hang or crash just because there is a future timestamp. After the build problem is fixed, it seems that there should still be new issue filed for Felix (or whereever this problem is) that addresses the stability issue.
        Hide
        Jill Sato added a comment -

        I changed the timezones on all machines in POOL-1 to be US/Pacific and now the zip distributions match the time of the system starting with gf-trunk-build-continuous #13598.
        Please confirm if this fixes your tests.

        Show
        Jill Sato added a comment - I changed the timezones on all machines in POOL-1 to be US/Pacific and now the zip distributions match the time of the system starting with gf-trunk-build-continuous #13598. Please confirm if this fixes your tests.
        Hide
        Jill Sato added a comment -

        Setting timezone to Pacific on all systems solves the problem. Thanks.

        TZ=US/Pacific

        Show
        Jill Sato added a comment - Setting timezone to Pacific on all systems solves the problem. Thanks. TZ=US/Pacific
        Hide
        Tom Mueller added a comment -

        Seems to have fixed the developer scenario benchmark.

        Show
        Tom Mueller added a comment - Seems to have fixed the developer scenario benchmark.

          People

          • Assignee:
            Jill Sato
            Reporter:
            Sanjeeb Sahoo
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: