summaryrefslogtreecommitdiff
path: root/indra/llplugin/llpluginprocesschild.cpp
diff options
context:
space:
mode:
authorRoger Luedecke <roger.luedecke@gmail.com>2026-07-31 11:12:58 -0700
committerAndrey Kleshchev <117672381+akleshchev@users.noreply.github.com>2026-09-08 19:04:09 +0300
commit6ed057a138954f083e04daeb06268ba5ba744bd2 (patch)
tree4cbc64ff8ef30002caaa49432b5736c8da169dfe /indra/llplugin/llpluginprocesschild.cpp
parent3ac6222c27a24737b21d73a12337d39155ffc445 (diff)
Notify waiting objects when mesh header retries are exhausted
LLMeshRepoThread::run()'s header-fetch loop silently dropped a request on final retry exhaustion (just a debug log), unlike the LOD and skin loops right next to it, which push into mUnavailableQ on the identical exhaustion condition so waiting objects get unstuck. Any LLVOVolume waiting on that mesh's header never received notifyMeshLoaded or a forced LOD fallback, leaving it at its placeholder shape permanently with no further retry. fetchMeshHeader() returns false when the local HTTP layer refuses to even enqueue the request (congestion), which is rare in ordinary play but close to guaranteed right after a teleport into a busy region, when a whole region's object list arrives at once and hits the fixed concurrent-request cap -- matching the reported symptom of mesh objects never rezzing after teleporting into crowded regions. Mirrors LLMeshHeaderHandler::processFailure(): push all LOD levels for the mesh onto mUnavailableQ so dependent objects fall back instead of waiting forever. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01J7R2Za4br1N947HEDgf8zr
Diffstat (limited to 'indra/llplugin/llpluginprocesschild.cpp')
0 files changed, 0 insertions, 0 deletions