Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-227094] Viewer floods the server with GroupProfileRequest due to persistent Notifications #5494

Closed
sl-service-account opened this issue Jun 4, 2019 · 1 comment

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 4, 2019

What just happened?

The viewer spams the region it logs into with GroupProfileRequests in rapid succession. as soon as the login is completed.

This image shows the LL release viewer (shrunk to fit) with 12 group notices, and a wireshark capture showing the resultant 72 (6 per notice!!) UDP requests
https://i.gyazo.com/bb4039ac25c4d65f86703d3538d7bee1.png

On another account I had 245 notices and generated over 750 requests (before the viewer timed out due to my debug) the 3:1 and 6:1 ratios are consistent.

What were you doing when it happened?

A firestorm user and OpenSim server developer uBit raised a Jira a while back (https://jira.phoenixviewer.com/browse/FIRE-19734) indicating that FS would spam the server with requests for groups that did not exist. While investigating this I have split the problem into two parts

  1. the spam

  2. the non-existent groups.

  3. The spam occurs on any grid and is evident on the LL viewer as well as FS, Alchemy and Kakoa (BD not tested but expected to behave the same)
    The spam is caused by the loading of persisted notification and invites from the disk cache. Each notification generates a minimum of 3 requests due to an underlying "feature" of the UI setup. As a result hundreds of requests can be generated if the user has many outstanding notices (which they invariably do)

  4. the missing groups is due to the cache not checking which grid sourced the notification. While this is more applicable to FS and viewers that are used on Open Sim it does apply to SL for the various test grids (agni, aditi, and internals)

What were you expecting to happen instead?

At most one request per unique group and only on the grid for which the notification makes sense.

Other information

The underlying UI issue, where the request is being triggered as part of the UI setup appears to extend to other areas which need to be examined. For example, opening a group chat will send two requests.

It is worth noting that the region replies to every one of the requests.

Attachments

Original Jira Fields
Field Value
Issue BUG-227094
Summary Viewer floods the server with GroupProfileRequest due to persistent Notifications
Type Bug
Priority Unset
Status Closed
Resolution Accepted
Reporter Beq Janus (beq.janus)
Created at 2019-06-04T00:54:29Z
Updated at 2020-09-22T19:20:14Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  "Is there anything you'd like to add?": 'The underlying UI issue, where the request is being triggered as part of the UI setup appears to extend to other areas which need to be examined. For example, opening a group chat will send two requests. \r\n\r\nIt is worth noting that the region replies to every one of the requests.\r\n',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Viewer',
  'Target Viewer Version': 'viewer-development',
  'What just happened?': 'The viewer spams the region it logs into with GroupProfileRequests in rapid succession. as soon as the login is completed.\r\n\r\nThis image shows the LL release viewer (shrunk to fit) with 12 group notices, and a wireshark capture showing the resultant 72 (6 per notice!!) UDP requests\r\n!https://i.gyazo.com/bb4039ac25c4d65f86703d3538d7bee1.png!\r\n\r\nOn another account I had 245 notices and generated over 750 requests (before the viewer timed out due to my debug) the 3:1 and 6:1 ratios are consistent.\r\n\r\n',
  'What were you doing when it happened?': 'A firestorm user and OpenSim server developer uBit raised a Jira a while back (https://jira.phoenixviewer.com/browse/FIRE-19734) indicating that FS would spam the server with requests for groups that did not exist.  While investigating this I have split the problem into two parts\r\n1) the spam\r\n2) the  non-existent groups.\r\n\r\n1) The spam occurs on any grid and is evident on the LL viewer as well as FS, Alchemy and Kakoa (BD not tested but expected to behave the same)\r\nThe spam is caused by the loading of persisted notification and invites from the disk cache. Each notification generates a minimum of 3 requests due to an underlying "feature" of the UI setup. As a result hundreds of requests can be generated if the user has many outstanding notices (which they invariably do)\r\n\r\n2) the missing groups is due to the cache not checking which grid sourced the notification. While this is more applicable to FS and viewers that are used on Open Sim it does apply to SL for the various test grids (agni, aditi, and internals) \r\n',
  'What were you expecting to happen instead?': 'At most one request per unique group and only on the grid for which the notification makes sense.',
  'Where': "At login, anywhere you like, it literally doesn't care.",
}
@sl-service-account
Copy link
Author

Beq Janus commented at 2019-06-05T12:56:12Z

Added patch against viewer release to prevent spam.

A simple time cache is maintained per group_id requested, based on the gFrameTime.

A subsequent request within a defined period (hardcoded constant set at 100ms) will be ignored.

This does not address the secondary issue related to multiple grids. 

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant