You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.
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
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
the spam
the non-existent groups.
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)
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.
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.",
}
The text was updated successfully, but these errors were encountered:
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
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
the spam
the non-existent groups.
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)
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
The text was updated successfully, but these errors were encountered: