Uploaded image for project: 'Snowstorm'
  1. Snowstorm
  2. STORM-1001

Viewer needlessly hits the "ObjectMedia" cap with thousands of requests

    Details

    • Type: Defect
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Sprint 12
    • Labels:
      None
    • Environment:
      Any Viewer 2 since changeset 03bdb3e84ee0 / code suggests platform independent
    • Approvals:
      Code Review, Product Owner
    • Acceptance Criteria:
      Hide
      Check description for repro: basically, verify that the secondlife.log doesn't show loads of :

      INFO: LLMediaDataClient::serviceQueue: Sending request for request: num=9753 type=GET ID=ea1a378d-328f-d024-671e-09da2a2d4dde face=-1 #retries=0

      anymore
      Show
      Check description for repro: basically, verify that the secondlife.log doesn't show loads of : INFO: LLMediaDataClient::serviceQueue: Sending request for request: num=9753 type=GET ID=ea1a378d-328f-d024-671e-09da2a2d4dde face=-1 #retries=0 anymore

      Description

      While looking through my secondlife.log I noticed the following:

      2010-11-14T19:50:41Z INFO: LLMediaDataClient::serviceQueue: Sending request for request: num=9753 type=GET ID=ea1a378d-328f-d024-671e-09da2a2d4dde face=-1 #retries=0

      Those 9753 cap requests occurred over the course of just over 2 hours. The sheer amount of them, coupled with frequently hitting the throttle limit didn't seem normal at all since objects with media on them are still rare and it seemed unlikely to encounter 9753 of them in the same region.

      Teleporting home where I knew there shouldn't be any objects with media on them some of the objects the viewer was hitting the ObjectMedia cap for were a "dinner table", a "side table", some plants, etc which very clearly suggests a bug.

      S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root cause of the bug:

      The header file suggests that:

      // The Media Tex Gen values are bits in a bit field:
      // +----------+
      // | .....TTM | M = Media Flags (web page), T = LLTextureEntry::eTexGen, . = unused
      // | 76543210 |
      // +----------+
      const S32 TEM_MEDIA_MASK		= 0x01;
      const S32 TEM_TEX_GEN_MASK		= 0x06;

      and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() each properly mask off the supplied parameter with their respective bit mask, setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has changed while the media flag hasn't (causing LLVOVolume::processUpdateMessage() to queue a request to the cap when it shouldn't).

      Changing it to:

      S32 LLTextureEntry::setMediaTexGen(U8 media)
      {
      	S32 result = setTexGen(media & TEM_TEX_GEN_MASK);
      	result |= setMediaFlags(media & TEM_MEDIA_MASK);
      	return result;
      }

      appears to resolve the issue completely (the cap isn't hit unless an object nearby has media on it, or changes its URL) but I'm much too unfamiliar with that part of the code to judge any impact.

      If my viewer floods the cap on a busy region at a rate of about 5,000 request/hour then a full region with 100 avies all on viewer 2 would cause 500,000 needless requests/hour on that region cap so this really could use some "Linden love" .

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                kitty.barnett Kitty Barnett
                Extended Group Visibility:
                jira-users
                Prod Owner Approved:
                Merov Linden
              • Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: