diff options
| author | Roger Luedecke <roger.luedecke@gmail.com> | 2026-07-31 11:12:58 -0700 |
|---|---|---|
| committer | Andrey Kleshchev <117672381+akleshchev@users.noreply.github.com> | 2026-09-08 19:04:09 +0300 |
| commit | 6ed057a138954f083e04daeb06268ba5ba744bd2 (patch) | |
| tree | 4cbc64ff8ef30002caaa49432b5736c8da169dfe /indra/llplugin/llpluginprocesschild.cpp | |
| parent | 3ac6222c27a24737b21d73a12337d39155ffc445 (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
