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.
I think it's still useful to know this to show up any errors early, but it's reasonable to still carry on rather than throw an exception.
Follow on from Diva's commit 9643792
Previously we used a heuristic of checking if the entry position is 0 to differentiate between Teleport and Cross, but that doesn't work anymore since we've started providing the precise entry position for cross, too. That's required in order to ensure that the user is allowed to enter the parcel that he's walking into.
