Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-74514

BigbluebuttonBN is polling the BigblueButton server too often

XMLWordPrintable

    • MOODLE_400_STABLE
    • MOODLE_400_STABLE
    • Hide

      The test is a partial test that will ensure that the meeting is updated regularly while we cache the information about the meeting.

      For Web Testing:

      For a given BigblueButtonBN activity called B1:

      1. Go the the B1 / Settings and check "Wait for moderator" checkbox
      2. Create a student user and enroll it into the course containing B1 as a student
      3. Open another window W2 (private window, so separate session)
      4. Login as a student
      5. Go to the B1 activity
      6. Ensure that the message "Waiting for a moderator to join." is displayed
      7. In the original window where the admin is logged in
      8. Go to the B1 activity (as an admin)
      9. Join the meeting
      10. Go back to the B1 tab/page so to check that the message 'The session is in progress.' is displayed for the admin
      11. Go back on the W2, where the student is logged in
      12. The join session button should be visible
      13. There should be a new "End session" button added to the page and the number of moderator should be 1

      For Mobile Testing:

      For a given BigblueButtonBN activity called B1 on the webbrowser interface:

      1. Create a teacher user and enroll it into the course containing B1 as a teacher
      2. Go the the B1 / Settings and check "Wait for moderator" checkbox
      3. In the "Role assigned during live session" add the teacher as a moderator (Add Role / Teacher / join session as "Moderator")
      4. Go to the B1 activity (as an admin)
      5. On the mobile APP login as a teacher
      6. Go to the BBB activity
      7. Join the meeting
      8. Go back on the Moodle Webbrowser version
      9. There should be a new "End session" button added to the page and the number of moderator should be 1
      Show
      The test is a partial test that will ensure that the meeting is updated regularly while we cache the information about the meeting. For Web Testing: For a given BigblueButtonBN activity called B1: Go the the B1 / Settings and check "Wait for moderator" checkbox Create a student user and enroll it into the course containing B1 as a student Open another window W2 (private window, so separate session) Login as a student Go to the B1 activity Ensure that the message "Waiting for a moderator to join." is displayed In the original window where the admin is logged in Go to the B1 activity (as an admin) Join the meeting Go back to the B1 tab/page so to check that the message 'The session is in progress.' is displayed for the admin Go back on the W2, where the student is logged in The join session button should be visible There should be a new "End session" button added to the page and the number of moderator should be 1 For Mobile Testing: For a given BigblueButtonBN activity called B1 on the webbrowser interface: Create a teacher user and enroll it into the course containing B1 as a teacher Go the the B1 / Settings and check "Wait for moderator" checkbox In the "Role assigned during live session" add the teacher as a moderator (Add Role / Teacher / join session as "Moderator") Go to the B1 activity (as an admin) On the mobile APP login as a teacher Go to the BBB activity Join the meeting Go back on the Moodle Webbrowser version There should be a new "End session" button added to the page and the number of moderator should be 1

      When we display the meeting page, we should poll the Bigbluebutton server to get fresh information about the current meeting's status. This is important, especially when we wait for a moderator to start the meeting.

      To avoid polling the server too many times we have setup a cache of 60 seconds (waitformoderator_cache_ttl).

      This would work ok, except for two points:

      1. The roomupdater script calls the meeting_info with updatecache parameter set to true. This should not be set to true, if not it will force a cache refresh every time.
      2. The retrieve_cached_meeting_info in the meeting.php class will call get_meeting_info without cache management if the get_meeting_info throws an exception. This second point was not actually visible we actually "fixed" the wait for moderator functionality (MDL-74052). 

      I set this ticket to the maximum priority here because the end result might be quite disastrous for the BigblueButton servers which would then be polled too many times. 

      A fix is in preparation.

        1. MDL-74514_v400_web_3.png
          MDL-74514_v400_web_3.png
          66 kB
        2. MDL-74514_v400_web_2.png
          MDL-74514_v400_web_2.png
          112 kB
        3. MDL-74514_v400_web_1.png
          MDL-74514_v400_web_1.png
          103 kB
        4. MDL-74514_v400_mobile.png
          MDL-74514_v400_mobile.png
          87 kB
        5. MDL-74514_master_web_3.png
          MDL-74514_master_web_3.png
          65 kB
        6. MDL-74514_master_web_2.png
          MDL-74514_master_web_2.png
          110 kB
        7. MDL-74514_master_web_1.png
          MDL-74514_master_web_1.png
          58 kB
        8. MDL-74514_master_mobile.png
          MDL-74514_master_mobile.png
          111 kB

            lmdavid Laurent DAVID
            lmdavid Laurent DAVID
            Shamiso Jaravaza Shamiso Jaravaza
            Victor Déniz Falcón Victor Déniz Falcón
            Angelia Dela Cruz Angelia Dela Cruz
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour
                1h

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.