|Anonymous | Login | Signup for a new account||2019-07-22 14:39 PDT|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008054||opensim||[REGION] OpenSim Core||public||2016-11-09 20:35||2019-02-06 11:29|
|Product Version||master (dev code)|
|Target Version||Fixed in Version||0.9.0|
|Summary||0008054: Link/Unlink prims take a long time and sometimes doesn't finish the operation|
|Description||At commit d5f376a4b10ffdb5acc17d4e350a0a523ba0e9f5 up to and including master, linking and/or unlinking objects seem to take a measurably longer time in master than it does prior to this commit. |
Prior to this commit (including release 0.8.x) the links and unlinks are quick, almost instant, in most cases.
The issue is relatively easily triggered, simply rez out a medium to high prim count object and try to unlink it. As the viewer shows the highlight updates of the object while its trying to unlink, it appears to unlink a few prims, stop for a few seconds, unlink a few more, stop for a few seconds, etc. until it's unlinked. In some cases it never finishes unlinking and in other cases the object can't be relinked once it has been unlinked... Or it can be relinked but it takes a lot of doing to get it to work (i.e. have to go out of edit mode, reselect the objects and try again; or simply spamming the CTRL + L keys until it finally takes it... and this method sometimes results in exceptions in the console)
The general rule of thumb to this issue seems to be that the more prims there are to unlink the worse it is and the more likely it is to stall while unlinking.
|Steps To Reproduce||These tests were performed on several different viewers including latest Firestorm and latest Sinularity, and also tested under ubODE as well as BulletSim with same results.|
1. Rez out a medium to high prim count object (I used an object consisting of appx 150 or so simple cubes for this test)
2. Unlink it
3. Try to link it back again
a. Often times this will fail or will be hard to do at very least
4. Try rezzing two copies of the object and select them both and try to unlink it
a. I have noticed that this resulted in about twice as worse performance due to double the amount of prims to unlink
5. It may be necessary to restart OpenSim in order to clean these objects up off the region since they sometimes get into a state where they can't be removed
|Additional Information||Git bisect results:|
d5f376a4b10ffdb5acc17d4e350a0a523ba0e9f5 is the first bad commit
Author: UbitUmarov <email@example.com>
Date: Thu Aug 25 09:51:34 2016 +0100
send selected objects Proprieties udp part outside update queues and as a physics single caps message per selection request
:040000 040000 430263b225c9e159a0fe6259bd2850a828f8f451 9187b7a4eac90f1da19bb5d8947aad4ca582dee2 M OpenSim
|Tags||No tags attached.|
|Git Revision or version number||Master|
|Run Mode||Standalone (Multiple Regions)|
The select/Deselect viewers protocol as always been very bad, and got worse.
Each request can contain a list of unrelated prims and selection is done by prims, and expects responses for prims.
to make things worse, things like physics shape type, gravity etc. must be send via http, so each response has udp and http parts, both required.
what viewers do on unlink is surreal. per each prim unlinked, they unselect all and select all again. And on this they even forget that they do send unrelated prims lists so they send requests per linkset.
This does grow exponentially with the number of prims
That commit is part of fixing the missing http part of the responses with its respective performance cost on a already bad situation
|ok think I improved it a bit on master|
Just tested master. This is actually quite a bit better than it was before. Tested linking and unlinking around the neighborhood of 300 prims; links and unlinks a lot smoother and very little to no stalling that I can observe.
Will leave this mantis open in case more testing is required?
|Haven't had an issue with this for a while so it seems to be resolved|
|Marked as Resolved but never closed, can be reopened if needed.|
|2016-11-09 20:35||mewtwo0641||New Issue|
|2016-11-10 06:43||UbitUmarov||Note Added: 0031267|
|2016-11-10 10:01||UbitUmarov||Note Added: 0031268|
|2016-11-10 16:57||mewtwo0641||Note Added: 0031269|
|2017-08-15 18:38||mewtwo0641||Note Added: 0032254|
|2017-08-15 18:38||mewtwo0641||Status||new => resolved|
|2017-08-15 18:38||mewtwo0641||Fixed in Version||=> 0.9.0|
|2017-08-15 18:38||mewtwo0641||Resolution||open => fixed|
|2017-08-15 18:38||mewtwo0641||Assigned To||=> mewtwo0641|
|2019-02-06 11:29||BillBlight||Note Added: 0034416|
|2019-02-06 11:29||BillBlight||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|