However, many locks remain since they may effectively be providing transactionality in some operations (e.g. prim updates across multiple tables).
These are candidates for being replaced with proper database transactions, since this would not block unrelated operations (e.g. land save and object save)
or unrelated operations on the same tables (e.g. storage of one linkset whilst another is being removed).
In practice, any performance deg due to contention is probably rare and short lived as the major prim operations are performed in memory and only persisted some time afterwards.
These locks are not necessary since the connection is taken from the underlying mysql pool and not shared.
Such locking is already not done by some other parts of OpenSim.Data.MySQL.
Pointed out by arribasim-dev
Disabled by default. Currently can only be enabled with console "debug lludp oqre start" command, though this can be started and stopped whilst simulator is running.
When a connection requires packet queue refill processing (used to populate queues with entity updates, entity prop updates and image queue updates), this is done via Threadpool requests.
However, with a very high number of connections (e.g. 100 root + 300 child) a very large number of simultaneous requests may be causing performance issues.
This commit adds an experimental engine for processing these requests from a queue with a persistent thread instead.
Unlike inbound processing, there are no network requests in this processing that might hold the thread up for a long time.
Early implementation - currently only one thread which may (or may not) get overloaded with requests. Added for testing purposes.
Also closes behaviours on disconnect instead of interrupt, though this makes no practical difference.
If existing behaviour is None, other added behavious will not take affect until None is removed (as this is an infinite wait until interrupted).
If n > 1 for RootTerseUpdatePeriod only every n terse update is actually sent to observers on same region, unless velocity is effectively zero (to stop av drift).
If n > 1 for ChildTerseUpdatePeriod only every n terse update is sent to observers in other regions, unless velocity is effectively zero.
Defaults are same as before (all packets are sent).
Tradeoff is reduction of UDP traffic vs fidelity of observed av mvmt.
Increasing n > 1 leads to jerky observed mvmt immediateley for root, though not on child, where experimentally have gone to n = 4 before jerkiness is noticeable.
Rapid polls are more expensive than triggered events (several polls vs one trigger) and may be problematic on heavily loaded simulators where many threads are vying for processor time.
A triggered event is also slightly quicker as there is no maximum 200ms wait between polls.
This is already going to be correctly set by WaitForUpdateAgent() earlier on in that method, which is always called where a callback to the originating region is required.
This kind of polling is very expensive with many bots/polling threads and appears to be the primary cause of bot falloff from the client end at higher loads.
Where inbound packet threads can't run in time due to contention and simulator disconnect timeout occurs.
This adds the "show stats", "stats record", etc. commands and information on available Threadpool threads, etc.
It also adds the Watchdog which logs warnings if time between executions is unexpectedly large.
This is to avoid issues where many bots connect to a single end point with multiple regions, where each region requires a long-lived poll connection for each bot.
This lock serialized all requests and made the inventory throttling in WebFetch redundant.
By moving this lock, two simultaneous requests may now take place which may help with http://opensimulator.org/mantis/view.php?id=7054
Move the experimental extra features functionality into the GridService. This sends default values for map, search and destination guide, plus ExportSupported control to the region on startup. Please watch http://opensimulator.org/wiki/SimulatorFeatures_Extras for changes and documentation.
These govern when AgentUpdates are sent to observers on position, rotation and velocity changes to an avatar (including the avatar themselves).
Higher values reduce AgentUpdate traffic but at a certain level will degrade smoothness of avatar and perceived avatar movement.
This covers event queue setup messages and some outgoing messages (e.g. EnableSimulator)
In my experience these messages are only useful if you really know what they mean and you're looking for them
Otherwise, they're quite spammy.
Event queue DebugLevel 1 is enabled with the "debug eq 1" console command
On non-HG this is on the only recognized failure state so we can return more information in the error result.
On HG there are multiple failure states which would require more work to distinguish, so currently return the unsatisfying "Internal Error" like some other existing calls.
This may have been the trigger CheckSendingPatchesToClients() dictionary out of sync exceptions in today's load test.
Don't need to check ContainsKey() since Remove() returns false on a request to remove a key that it doesn't have
Allows experiments in manually reducing updates under heavy load.
Activated by "debug scene set client-upd-per" console command.
In a simple test, can send as few as every 4th update before observed movement starts becoming disturbingly rubber-banded.
Corresponds to ResendAppearnceUpdates setting in [Appearance] in OpenSim.ini
This was originally implemented to alleviate cloud appearance problems but could be too expensive with large numbers of avatars.
This governs when child agent position changes are sent to neighbouring regions.
Corresponding config parameter is ChildReprioritizationDistance in [InterestManagement] in OpenSim.ini
For test purposes.
This gives a count of all requests made to the remote inventory service.
This is finer grained than inventory.httpfetch.ProcessedFetchInventoryRequests since such a request can be comprised of many individual inv service calls.
In addition, this will count requests that don't go through the HTTP inventory fetch (e.g. HG, archiving, etc.)
A stop gap solution - a better one may be to improve stats display on simulator-side.
Caps information is still accessible via the "show caps stats by user" and "show caps stats by cap" commands
This is for testing purposes (chiefly http://opensimulator.org/mantis/view.php?id=7054) so many not be permanent
Setting this will change the xinventory request timeout from the simulator from the default 100 seconds
For each service endpoint (e.g. posts to the xinventory service), a stat is available which shows the number of requests received and moving average per second
The full name is "service.<http-method>:<path>.requests (e.g. service.POST:/xinventory.requests)
Fixes http://opensimulator.org/mantis/view.php?id=7280
It can't be done this way because the stats data needs to show up on the console at all log levels, not just debug.
But this means setting it to log at fatal, which is not appropriate for this stuff in the log.
I understand the desire but this has to be done some other way, perhaps by (yet another) config parameter.
Also, this was already being done with the ClientStatsReport but that also should be done in another way, I think.
This reverts commit 5d53412766.
I forgot that a null 'their version' would not be passed over the wire and ends up as an empty string instead (like older simulators).
So instead pass through the correct simulator protcol version instead (SIMULATOR/0.3) when querying from login or hg login.
Also removes a debug console write for agent limit accidentally left in for the same commit.
Relates to mantis 7276
Despite the comments in the code, it appears that the issue where the .NET performance counter was wrongly idle time time on Mono was fixed in 2009.
https://bugzilla.novell.com/show_bug.cgi?id=468625
Which means that the workaround is no longer necessary and produces bad results instead.
Another manifestation of this bug is that after a Hypergrid teleport, when you click on one of the avatar's attachments the object doesn't show its name. This means that the viewer knows the attachment is there, but the simulator does not.
The problem was caused by treating Hypergrid teleports as if they're Logins (because the teleport flag ViaLogin is enabled).
This may fix: http://opensimulator.org/mantis/view.php?id=7238
This may fix: http://opensimulator.org/mantis/view.php?id=7220
This caused the client to stop responding, and even the simulators to have problems. The solution is to disallow crossing before the previous cross has completed.
The "Sculpt" field in prims is used for both Sculpties (where the assets are Textures), and real meshes. Meshes require a different download URL than textures.
When sending an ImprovedInstantMessage to a group, the IM's binary bucket is supposed to contain the group's name (this is what SL does). Singularity uses this to show the group name when it shows the message at the bottom of the viewer for a few seconds: "[Group Name] From User: Message". Before this update, the group name was empty ("[]").
This update doesn't have any visible effect in Firestorm, because it doesn't use the group name sent in the IM.
This, by default, enables terrain patches being sent to each avatar
from the avatar away (rather than the old outside-in pattern), only
sending terrain patches within the avatars view distance (making
view loading quicker), and sending multiple terrain patches per
protocol packet (making terrain loading and editing quicker).
when registering a new region.
Adds parameter "[GridService]SuppressVarRegionOverlapCheckOnRegistration=false"
that can be turned on to suppress the error check if a simulator's database
has old regions that overlap.
co-op should be more stable as it doesn't abort threads, which can trigger virtual machine instability
This change will be invisible to users as script DLLs are recompiled automatically where necessary, though the change won't take affect until the next simulator restart.
This change has no effect on existing script state.
If you want to continue using abort, set ScriptStopStrategy = abort in the [XEngine] section of OpenSim.ini
As per http://msdn.microsoft.com/en-us/library/system.random%28v=vs.100%29.aspx, the .NET Random class is not thread-safe.
If called by multiple threads at once, methods may return 0.
Except for llRand(), other OpenSimulator code did not lock before calling a shared Random instance.
This commit adds a ThreadSafeRandom class that extends Random but does internal locking so that it is thread-safe.
This change is invisible to existing callers and the explicit locking in the llFrand() implementation is now redundant.
We have to do this since we can't unload existing DLLs if they're all in the same AppDomain.
But we can still update the underlying DLL which will be used in the next simulator session.
Code was identical apart from error logging, but if there are failures creating these directories then you'll be
seeing lots of errors anyway, and these will be more informative
In commit e6080a38 (Wed Mar 19 00:29:36 2014) I renamed this from "debug stats record start|stop"
Unfortunately, I didn't do this fully so before this commit "stats record start|stop" will report a usage failure with the old debug text.
Unfortunately this is in the 0.8 release. The workaround is to repeat the last command twice (e.g. "stats record start start")
This will show an approximate grid size that doesn't count regions that are hyperlinks
Not particularly trustworthy since it will still count regions that are not active but were not deregistered (deliberately or due to simulator crash or similar)
"show regions" drops the owner id column but is till present in "show region"
"show regions" name column expanded to allow for longer hg regions (probably still too short, may eventually have to truncate rather than taking up huge screen space)
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
If the C# column can't be found in the positionMap (but the line can),
use the map immediately after it while correcting for the offset,
unless that results in an LSL position before the previous LSL position
in the positionMap.
The idea behind this heuristic is that in most, if not all cases C#
consumes more characters than LSL (for example LSL_Types.LSLInteger
instead of just 'integer').
Thus if the distance between the columns of two markers differ in
the C# and LSL file, the distance in the C# file will be larger.
Moreover, we can assume that every time this happens we will have
a marker at the beginning of the longer 'keyword', because those
keywords were generated by us in the first place.
For example:
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
1 2
will always have markers at the beginning of the long keywords
'LSL_Types.LSLInteger' and 'LSL_Types.LSLString'.
If an error is generated in between (for example at the beginning
of the function name 'f2') then the correct position is found
by using an offset relative to 2 rather than 1.
Note that a case where this isn't working correctly is
when the user adds extra spaces. For example:
LSL: integer f2( string s)
would still use the start of 'string' as reference and
then go backwards 3 characters only because the corresponding
C# still looks like
C#: LSL_Types.LSLInteger f2(LSL_Types.LSLString s)
^ ^
only 3 chars difference
and the reported error at 'f2' would be here:
LSL: integer f2( string s)
^
This can only be fixed by generating a mapping for 'f2' itself, or
generating a mapping whenever the amount of spaces is changed.
When a compile error reports a colum/error that is not an exact
match in the positionMap dictionary, the last position in the
map with a line number and position before the reported error
should be returned.
The old code had the following problems:
1) It returns l,c - which are line and column of the C# file, not LSL.
2) It doesn't set l to 'line' when the map has an entry with 'line'.
3) It sorts the map without taking columns into account, which may
result in a random order of the columns. With my mono implementation
the columns were reversed in order.
For example, if the map contains the following lines:
99,5,49,10
100,30,50,10
100,40,1,0
101,5,51,10
and a translation of 100,35 was requested,
then the old code would compare '100' with the keys in
the first column - setting l to that key while it is
smaller. Hence, l is set to 99.
Then it finds the key 100 and doesn't update l.
Because of the reversed sort order, it first compares
the column 35 with 40, finding that it is smaller
and therefore it stops; returning 99,1 instead of finding
the correct 100,30 entry and returning 50,10.
This patch causes 50,10 to be returned.
The remaining problems after this patch are:
1) The sorting might not be necessary at all.
2) The is code duplication (I fixed both instances,
but really there should be no code duplication
imho).
Justin Clark-Casey (justincc)