| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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
|
