As far as I know, this was only used by the IBM Rest modules, much of which has been commented out for a very long time now. Other similar code uses HTTP or stream handlers instead.
So commenting this out to reduce code complexity and the need to make this facility consistent with the others where it may not be used anyway.
If this facility is actually being used then please notify me or uncomment it if you are core.
This allows us to associate debug logging messages with the right request.
It also allows us to put a request number on 'long request' logging even if other debug logging is not enabled, which gives us some idea of whether every request is suffering this problem or only some.
This is a separate internal number not associated with any incoming number in the opensim-request-id header, this will be clarified when logging of this incoming request number is re-enabled.
This commit also adds port number to HTTP IN logging to allow us to distinguish between different request numbers on different ports.
This is only printed if debug http level >= 4 and the request didn't take more than the time considered 'long', in which case the existing log message is printed.
This displaces the previous log levels 4 and 5 which are now 5 and 6 respectively.
This is for debugging purposes.
This is controlled via the "debug http" command which can already log incoming requests.
This now gains a mandatory parameter of in, out or all to control what is logged.
Log messages are also shortened and labelled and HTTP IN or HTTP OUT to be consistent with existing UDP PACKET IN and PACKET OUT messages.
This resends appearance uuids to avatars in the scene once a minute.
I have seen this help in the past resolve grey appearance problems where viewers have for unknown reasons sometimes ignored the packet.
The overhead is very small since only the UUIDs are sent - the viewer then requests the texture only if it does not have it cached.
This setting will not help with cloudy avatars which are usually due to the viewer not uploading baked texture data or uploading something that isn't valid JPEG2000
This is because libopenjpeg 1.5 appears to require a minimum of glibc 2.14, whereas at least one fairly recent distro (openSUSE 11.4 from 2011-03-10) only has glibc
Further investigation pending.
Among other things this allows pCampbot to work under Windows since libopenmateverse now ships the same log4net.dll (publicly signed) as OpenSimulator
This also updates the libopenmetaverse embedded libopenjpeg from 1.3 to 1.5.
DLL naming and mapping for non-Windows libopenjpeg changes to remove version number to make future udpates easier and bring it into line with names of other shipped DLLs.
libopenjpeg updates have been made for OSX, Windows (32 and 64 bit) and Linux (32 and 64 bit). Please report any issues.
Make AssetServiceConnector return more useful data on failure, such as what DLL it was trying to load
Allow LocalAssetServiceConnector.GetData() to work without a cache present, as works for the other lasc Get* methods.
This is to resolve a problem where an asset marked as local but not temporary but still used in the scene would be removed.
The timed expiry scan no longer tries to refetch assets from the scene that are not currently in the cache - this is not helpful since it just drags a lot of data into the cache that may never be referenced.
This removes the DeepScanBeforePurge option since setting this to false will introduce the above problem. This previously had a default of true.
Viewer LL 3.3.4 and before sometimes fail to properly redisplay dynamic textures that have a small data length compared to pixel size when pulled from cache.
This appears to happen when the data length is smaller than the estimate discard level 2 size the viewer uses when making this GetTexture request.
This commit works around this by always regenerating dynamic textures that fall below this threshold rather than reusing them if ReuseDynamicTextures = true
This can be controlled by the [Textures] ReuseDynamicLowDataTextures config setting which defaults to false.
This is because recent viewers (3.2.1, 3.3.4) and probably earlier ones using the http GetTexture capability will sometimes make such invalid range requests.
This appears to happen if the viewer's estimate of texture sizes at discard levels > 0 (chiefly 2) exceeds the total texture size.
I believe this does not normally happen but can occur for dynamic textures with are large but mainly blank.
If this happens, returning a RequestedRangeNotSatisfiable will cause the viewer to not render the texture at the final resolution.
However, returning a PartialContent (or OK) even with 0 data will allow the viewer to render the final texture.
SignpostMarv