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.
are kept on another. When users rez items from inventory or take objects from world, an HG-like asset copy takes place between the 2 servers, the world asset server and the user's asset server. This makes the simulators independent of the central asset server.
Note that this an advanced configuration and requires some security strengthening coming up.
On successful teleports this error wasn't actually shown to the user. But on failed teleports this error could hide the true cause of the failure. For example, attempting to use a Landmark that's more than 4095 regions away would result in two warnings appearing in the viewer: "Region too far" and "Destination could not be found". The second message hid the first one, so it wasn't obvious to the user what is actually the problem.
