This commit also fixes the log message "Region already exists in coordinates <{0},{1}>": it was actually showing the *requested* coordinates, instead of the coordinates of the previously-existing link.
This was because attributes were not being included in the transformation, hence losing the script state identity.
Symptoms are messages like "[SCENE OBJECT GROUP]: SavedScriptState element had no UUID in object test box"
Regression since the conference code merge. Regression test extended for this case.
Relates to http://opensimulator.org/mantis/view.php?id=7439
it does not consider GridUser as a viable source for residents' data.
it does not consider Friends, Inventory Creators to be trusted at all. There are lots of broken entries in existence.
There are lots of broken creator data fields in assets.
The following issues arise from the broken data in the old User Management Module:
failing HG IM
failing HGFriends Requests
Signed-off-by: BlueWall <jamesh@bluewallgroup.com>
The document here has no <?xml declaration. Though ideally it may be present, in practice it has not been added as the data here is embedded within an asset
On Mono 3.2.8 and probably other versions, calling WriteEndDocument() without a declaration does nothing.
On Windows .NET, the same operation throws a "Document does not have a root element" exception which may be contributing to Mantis 7397 and possibly 7439
This matches Linden Lab behaviour and what was already possible via shift-copy.
Transfer would not apply here as the owner and copier are the same.
This is the only functional change, all other current take copy logic remains the same.
Adds regression tests around relevant take copy cases.
This eliminates spurious network calls and failure reporting.
This is done by adding RegionFlags to the GridRegion returned data in a backward compatible way as an alternative to multiple IGridService.GetRegionFlags() calls
Using a simulator or a grid service older than this commit will just see previous behaviour.
This UUID gatherer provides a superset of the previous gatherer's functionality
as it also allows the caller to control gathering iterations for load purposes.
Instead, the failure information is effectively added to the memory cache (so no persistence over simualtor sessions).
A future improvement may be to invalidate negative cache results after some time has passed in case the failure was transient.
Looks to resolve http://opensimulator.org/mantis/view.php?id=7382
This is to achieve a clean separation of concerns - the watchdog is an inappropriate place for work management.
Also adds a WorkManager.RunInThreadPool() class which feeds through to Util.FireAndForget.
Also switches around the name and obj arguments to the new RunInThread() and RunJob() methods so that the callback obj comes after the callback as seen in the SDK and elsewhere
This improves upon the earlier naive simply queueing immplementation.
Threshold is 30 seconds. If this happens to a user they can relog and fetch will be reattempted.
This is to enable an imminent change where incoming HG scene object fetching can assess the time taken by each request rather than being forced to perform all requests in one call.
Soon, this will replace the existing UuidGatherer since it is both simpler and more flexible.
This is to reduce the potential for overload of the threadpool if there are many simultaneous requets in high concurrency situations.
Currently only applied to AvatarProperties and GenericMessage requests.
This shows named threadpool calls (excluding timer and network calls) that are currently queued or running.
Also shows total of labelled and any anonymous calls.
Instead of processing all incoming attachment scene object concurrently, process them consecutively to eliminate potential overload from this source.
This is a naive implementation because it does not currently account for slow foreign asset services.
Although it may take longer, this approach may also improve attachment visibility for HG avatars
since the scene object is now always added to the scene after receiving assets from the foreign service and not before.
This is because objects with lots of parts can have a lot of xml to load into memory, and this has been seen to have a noticeable performance impact.
Whereas streaming has been seen to reduce the impact in normal serialization.
Implmentation is messy but I couldn't see a better way of doing it when you can't assume that you know the exact structure of the input XML.
This code originates from when IEntityTransferModule was shared rather than one per region.
Now it's one per region we know that callers are always in the same scene as the module.
Attachment persistence is not handled in this way and this just results in a load of busy work until a check in each SOG terminates a backup check for attachments anyway.
Reading large XML documents (e.g. complex attachments) is CPU expensive - this must be done as few times as possible (preferably just once).
Reading these documents into XmlDocument is also more resource intensive than using XmlTextReader, as per Microsoft's own publication "Improve .NET Application Performance and Scalability"
Optimization of other cases will follow if this change is successful.
