Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      1.0-japan-m9, 1.0-m10, 1.0-m11, 1.0-m12, 1.0-pre-beta-1, 1.0-beta-1

      Description

      SSE reconnects after losing it's connection, however if the client is hibernated completely (e.g. closing a laptop) then SSE stops completely and does not reconnect again after reopening the laptop.

      Scenario
      1. Start a job
      2. View the activity of the pipeline in blue ocean
      3. close your laptop lid until the run finishes
      4. open your laptop lid and see that the run is still executing

      We need some way of detecting that we were in hibernation and, once detected, reload the page completely, forcing an update of the UI and a restarting of SSE etc.

        Attachments

          Issue Links

            Activity

            Hide
            tfennelly Tom FENNELLY added a comment -

            Michael Neale right, but was removed before I got a chance see what was causing it. I have a feeling something is in there hogging the even loop and this might have been able to highlight that. Anyway ... not to worry ... I'll see can I replicate that locally with ngrok or other.

            Show
            tfennelly Tom FENNELLY added a comment - Michael Neale right, but was removed before I got a chance see what was causing it. I have a feeling something is in there hogging the even loop and this might have been able to highlight that. Anyway ... not to worry ... I'll see can I replicate that locally with ngrok or other.
            Hide
            michaelneale Michael Neale added a comment -

            Yeah increased timeout looks better, so worth a try.

            Tom FENNELLY it literally was picked up in dogfood, that is why it was rolled back, so it was doing its job.

            Show
            michaelneale Michael Neale added a comment - Yeah increased timeout looks better, so worth a try. Tom FENNELLY it literally was picked up in dogfood, that is why it was rolled back, so it was doing its job.
            Hide
            tfennelly Tom FENNELLY added a comment -

            Cliff Meyers I raised it to 20 seconds and created another PR. I don't think we should raise it any more than that ... def not minutes. If it does not work at 20s, then we have a much bigger issue somewhere else causing the event loop to be hogged and that should be fixed Vs tweaking this.

            As for debugging ... that makes sense because when you set a breakpoint you are blocking the loop. We should probably only turn this on in production coz what you describe would be very irritating during dev. Or, find an easy way of turning it off locally e.g. something in localStorage that gets remembered.

            Show
            tfennelly Tom FENNELLY added a comment - Cliff Meyers I raised it to 20 seconds and created another PR. I don't think we should raise it any more than that ... def not minutes. If it does not work at 20s, then we have a much bigger issue somewhere else causing the event loop to be hogged and that should be fixed Vs tweaking this. As for debugging ... that makes sense because when you set a breakpoint you are blocking the loop. We should probably only turn this on in production coz what you describe would be very irritating during dev. Or, find an easy way of turning it off locally e.g. something in localStorage that gets remembered.
            Hide
            cliffmeyers Cliff Meyers added a comment -

            This probably explains some odd behavior I saw yesterday where the app was refreshing itself while I was debugging JS in the browser. Maybe we should significantly raise the threshold to a min, or even five?

            Show
            cliffmeyers Cliff Meyers added a comment - This probably explains some odd behavior I saw yesterday where the app was refreshing itself while I was debugging JS in the browser. Maybe we should significantly raise the threshold to a min, or even five?
            Hide
            tfennelly Tom FENNELLY added a comment -

            James Dumay so what's the plan then if we can't use dogfood to diagnose issues like this? << Michael Neale I though that was the main idea of it (hence the name).

            I tried yesterday and did not see the issue you called out. I'd imagine we might want to lengthen the tolerance.

            Show
            tfennelly Tom FENNELLY added a comment - James Dumay so what's the plan then if we can't use dogfood to diagnose issues like this? << Michael Neale I though that was the main idea of it (hence the name). I tried yesterday and did not see the issue you called out. I'd imagine we might want to lengthen the tolerance.
            Hide
            jamesdumay James Dumay added a comment -

            Tom FENNELLY we had to revert this as it was causing random page refreshes in Chrome and Safari https://github.com/jenkinsci/blueocean-plugin/pull/435/commits

            Show
            jamesdumay James Dumay added a comment - Tom FENNELLY we had to revert this as it was causing random page refreshes in Chrome and Safari https://github.com/jenkinsci/blueocean-plugin/pull/435/commits
            Hide
            cliffmeyers Cliff Meyers added a comment -

            Just a few random ideas for this ticket...

            I've done this in other apps simply by using a setTimeout that stores the current epoch millis and periodically runs, checking if current millis has exceeded last stored millis by some arbitrary threshold which then marks the page as "stale." We might consider Moment instances for this instead, in case time zone is changed on the PC. Would have to check if the setTimeout continues to run immediately after computer exits hibernate but before browser gets focus; otherwise maybe a web worker can be guaranteed to run immediately after the computer wakes up? (Not sure on how different browsers handle that)

            Might make sense for this logic to live in blueocean-web, so various plugins could benefit from it, but if it overcomplicates things perhaps not.

            If we detect the page is stale, we can fire location.reload().

            Show
            cliffmeyers Cliff Meyers added a comment - Just a few random ideas for this ticket... I've done this in other apps simply by using a setTimeout that stores the current epoch millis and periodically runs, checking if current millis has exceeded last stored millis by some arbitrary threshold which then marks the page as "stale." We might consider Moment instances for this instead, in case time zone is changed on the PC. Would have to check if the setTimeout continues to run immediately after computer exits hibernate but before browser gets focus; otherwise maybe a web worker can be guaranteed to run immediately after the computer wakes up? (Not sure on how different browsers handle that) Might make sense for this logic to live in blueocean-web, so various plugins could benefit from it, but if it overcomplicates things perhaps not. If we detect the page is stale, we can fire location.reload().
            Hide
            jamesdumay James Dumay added a comment -

            We should do this on the:

            • Dashboard
            • Pipeline Summary
            • Pipeline Result
            Show
            jamesdumay James Dumay added a comment - We should do this on the: Dashboard Pipeline Summary Pipeline Result

              People

              • Assignee:
                tfennelly Tom FENNELLY
                Reporter:
                jamesdumay James Dumay
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: