| Commit message (Collapse) | Author | Files | Lines |
|---|
|
directory with any associated module-specific classes.
* Each module directory is currently inside one of the following category folders: Agent (Anything relating to do with Client<->Server communications.), Avatar (Anything to do with the avatar or presence inworld), Framework (Classes modules can use), Grid (Grid traffic, new OGS2 grid comms), Scripting (Scripting functions, etc), World (The enrivonment/scene, IE Sun/Tree modules.)
* This should be moved into a seperate project file.
|
|
too many other debug messages.
|
|
(this took a while to run).
|
|
|
|
isn't useable yet
|
|
|
|
OpenSim.Framework.Communications.Limit
|
|
'already dispatched' message completely temporarily
* I believe that if the Linden client has not started to receive a texture after 15 seconds, it re-requests it.
* My hypothesis is that the texture packets are often still in the texture queue (esp. if the client has just cleared its cache), so another load of packets get added...
* If this is the cause, resolution is going to be rather complicated.
|
|
requests for missing textures
* Also minor logic change so that we actually do retry missing texture requests (we weren't before)
|
|
|
|
when we start dropping requests
|
|
n=5), we now drop the subsequent requests
* This may improve region memory usage
* This is a short-term response to a problem whereby some clients keep requesting the same texture even after we've sent it
* This treats the symptom rather than the cause.
* n can be adjusted by changing the constant at the top of UserTextureDownloadService if necessary
|
|
already have received
* The warning will be
[USER TEXTURE DOWNLOAD SERVICE]: Received {0} requests for already dispatched texture {1} from client {2}
This is to see whether the texture packet queue memory leak is caused by clients continually re-requesting textures they should already have
|
|
|
|
AssetCache for it if we know it's missing.
|
|
textures (probably for some good reason) by dropping all subsequent requests after the first reply.
* Print out a console message every 20 tries rather than every single one.
* This weakens the problem but does not eliminate it
|
|
* Reduce 'asset not found' console debug spam
|
|
an image
* This might stop some client's constant requests for unfound textures, which is a candidate for the memory leak
* If a texture is not found then the "Image not found" texture will now be displayed clientside
* If it works, this should resolve mantis 676
* Non texture image requests do not receive this packet yet
* This will require a prebuild
|
|
TextureSender
|
|
* Moved Flush into Close since it's always done in that order.
* Minor renamings
* Reversed if for clarity
|
|
|
|
|
|
data from the asset server
* This should stop the constant increase in the download requests statistics
* If you see stat numbers for download requests which are far from what you'd expect, please report
|
|
|
|
* This fixes some of the 'runaway downloads' problem but not all of it
* Also fix up logging messages so texture requests are reported as such rather than as assets
|
|
* The reason why pending downloads tick ever upwards is because missing assets are never signalled to the TextureSender
* Rectifying this is not straightfoward, but this will constitute the next patch.
* This does not explain the memory leak.
|
|
|
|
memory
* However, I'm no longer sure they were even a big contributory factor (to this particular leak, there are other causes of other leaks). I need better measurement techniques
* Removed most of my debugging gawp
|
|
Just want to try this out on windows quickly.
|
|
|
|
|
|
|
|
leaving region.
|
|
|
|
* fixed Cancel bug
|
