Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-272

workspace page delivers out-dated files

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Cannot Reproduce
    • Component/s: core
    • Labels:
      None
    • Environment:
      Platform: All, OS: All
    • Similar Issues:

      Description

      I browse a workspace (in my case on a build slave) and view some generated
      files. Then I re-build the project and try to look at the new generated files.

      Expected: new contents
      Experienced: old contents as seen when I first looked at it

        Attachments

          Issue Links

            Activity

            Hide
            kohsuke Kohsuke Kawaguchi added a comment -
                • Issue 390 has been marked as a duplicate of this issue. ***
            Show
            kohsuke Kohsuke Kawaguchi added a comment - Issue 390 has been marked as a duplicate of this issue. ***
            Hide
            kohsuke Kohsuke Kawaguchi added a comment -

            Bumping up the priority since another report was filed for this bug.

            Show
            kohsuke Kohsuke Kawaguchi added a comment - Bumping up the priority since another report was filed for this bug.
            Hide
            gradopado gradopado added a comment -

            I still have to clear the cache of my Firefox in order to get the latest build
            artifacts. I mean when accessing "latestSuccessful", where the URL is always the
            same but the files change.

            Hudson version 1.152

            Show
            gradopado gradopado added a comment - I still have to clear the cache of my Firefox in order to get the latest build artifacts. I mean when accessing "latestSuccessful", where the URL is always the same but the files change. Hudson version 1.152
            Hide
            mindless Alan Harder added a comment -

            As far as I can tell, the original bugfix is working correctly. It is not clock
            difference between master-slave that makes a difference, but clock difference
            between where the workspace resides (in this case, slave machine) and the client
            system where your browser is running. If Hudson sends back an Expires header
            for 14:00 but your system thinks it is only 13:57 then for the next couple
            minutes your browser won't even send a HTTP request for that cached file.. but
            once the client system's clock does reach 14:00 then another time clicking that
            link does check with the server and get the latest file content.

            Net effect: you only see old content if:
            a) Your client system's clock in N minutes behind the system where the build runs
            b) A build runs
            c) Within N minutes of when file X is written during that build:
            1) You access file X in the workspace browser
            2) Another build runs
            3) You access file X again

            A lot to happen in that time window.. but, if we do want to avoid this case then
            the Expires header probably should be set even earlier. Rather than matching
            the Last-Modified date, make it even earlier to account for clock differences.
            Unfortunately, Stapler's serveFile method doesn't currently have any way to do
            this.. any expiration value <= 0 just uses the Last-Modified value. Maybe
            stapler should only do this for == 0 (which is what the javadoc says) and use
            the value as a delta for both positive and negative.. then we could pass
            -600000L or something.

            Side note: only Expires header has this problem.. Last-Modified is NOT compared
            to your client system's clock.. your browser remembers this value, and when it
            does send another HTTP request (current time is past Expires time) then it just
            sends that same value in the request, and the SERVER compares that value to the
            current timestamp of file X.

            Show
            mindless Alan Harder added a comment - As far as I can tell, the original bugfix is working correctly. It is not clock difference between master-slave that makes a difference, but clock difference between where the workspace resides (in this case, slave machine) and the client system where your browser is running. If Hudson sends back an Expires header for 14:00 but your system thinks it is only 13:57 then for the next couple minutes your browser won't even send a HTTP request for that cached file.. but once the client system's clock does reach 14:00 then another time clicking that link does check with the server and get the latest file content. Net effect: you only see old content if: a) Your client system's clock in N minutes behind the system where the build runs b) A build runs c) Within N minutes of when file X is written during that build: 1) You access file X in the workspace browser 2) Another build runs 3) You access file X again A lot to happen in that time window.. but, if we do want to avoid this case then the Expires header probably should be set even earlier. Rather than matching the Last-Modified date, make it even earlier to account for clock differences. Unfortunately, Stapler's serveFile method doesn't currently have any way to do this.. any expiration value <= 0 just uses the Last-Modified value. Maybe stapler should only do this for == 0 (which is what the javadoc says) and use the value as a delta for both positive and negative.. then we could pass -600000L or something. Side note: only Expires header has this problem.. Last-Modified is NOT compared to your client system's clock.. your browser remembers this value, and when it does send another HTTP request (current time is past Expires time) then it just sends that same value in the request, and the SERVER compares that value to the current timestamp of file X.
            Hide
            mindless Alan Harder added a comment -

            closing old issue

            Show
            mindless Alan Harder added a comment - closing old issue

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              gradopado gradopado
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: