fix(shared): ConnectionLimiter retains zero-count map entries on Release (memory leak)
I maintainer di solito rispondono entro 3 giorni
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 78/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Tranquilla
- Stack tecnologico
- go
- Ambito
- networking
Direzione di ricerca
Inizia da packages/shared/pkg/connlimit/limiter.go, in particolare da Release e dalle operazioni concorrenti sulla map, quindi leggi i casi correlati in packages/shared/pkg/connlimit/limiter_test.go. Esegui i test di connlimit e riproduci lo scenario con 10,000 chiavi. Il lavoro è completato quando le chiavi rilasciate non rimangono più nella map, mentre il comportamento esistente del limite e del rilascio concorrente continua a superare i test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
ConnectionLimiter in packages/shared/pkg/connlimit tracks and enforces per-key concurrent connection limits. When connections are acquired and subsequently released back to zero, Release(key) decrements the counter to 0, but never removes the key entry from the underlying concurrent map (smap.Map[*atomic.Int64]).
For long-running proxy nodes (client-proxy and orchestrator/pkg/tcpfirewall) handling high request volume across ephemeral client IPs or sandboxes, inactive keys remain permanently allocated in memory with count 0, causing steady memory accumulation over time.
Root Cause
Release(key) decrements counter.Load() to 0 via CompareAndSwap(current, current-1) but lacks eviction logic when current - 1 == 0. Calls to Remove(key) are only manually issued upon sandbox deletion in orchestrator, leaving generic HTTP proxy and TCP firewall IP keys orphaned forever.
| Setting / Factor | Current Value / State | Intended / Expected |
|---|---|---|
| File / Component | packages/shared/pkg/connlimit/limiter.go:L48-L63 |
Automatic zero-count key eviction |
| Map Retention | Retains zero-count keys indefinitely ((N_{\text{total_unique_keys}})$) | Evicts zero-count keys on release ((N_{\text{active_concurrent_keys}})$) |
Reproduction Steps
- Acquire and release 10,000 unique keys using
TryAcquire(key, limit)followed byRelease(key). - Inspect
limiter.connections.Count(). - Observed result:
Count()returns10000(10,000 zero-count map entries retained). - Expected result:
Count()returns0.
limiter := connlimit.NewConnectionLimiter()
for i := 0; i < 10000; i++ {
key := fmt.Sprintf("key-%d", i)
limiter.TryAcquire(key, 5)
limiter.Release(key)
}
// limiter.connections.Count() remains 10000
Technical Context
- Files affected:
packages/shared/pkg/connlimit/limiter.go,packages/shared/pkg/connlimit/limiter_test.go - Subsystem: Shared / Client Proxy / Orchestrator TCP Firewall
- Impact: Medium (Memory accumulation on edge proxy nodes)
Proposed Changes
| # | Change | File(s) Affected | Complexity |
|---|---|---|---|
| 1 | Atomically evict zero-count keys in Release(key) using RemoveCb |
packages/shared/pkg/connlimit/limiter.go |
Low |
| 2 | Add unit tests verifying zero-count map key eviction | packages/shared/pkg/connlimit/limiter_test.go |
Low |
- Lingua principale
- Go
- Stelle
- 1.7k
- Fork
- 458
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di e2b-dev/runtime
-
[Bug]: flock() on a mounted volume hangs forever (mount is missing `nolock`)Forse già presa @AdaAibaby l’ha presa 28 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 3 giorni
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running stateForse già presa @AdaAibaby l’ha presa 44 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 3 giorni
-
kernel: ipv6.disable=0 with no IPv6 routing causes Happy Eyeballs latency on all outbound sandbox connectionsForse già presa @AdaAibaby l’ha presa 48 giorni fa. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 86/100
I maintainer di solito rispondono entro 3 giorni
-
fix(envd): malformed error message %!w(<nil>) when watch path is not a directoryForse già presa @chill-czar l’ha presa 48 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 3 giorni
-
fix(api): POST /sandboxes/{id}/connect accepts non-positive timeout values causing immediate terminationForse già presa @chill-czar l’ha presa 48 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 3 giorni
Tutte le issue di e2b-dev/runtime
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
JuliusBrussee/caveman#1189 ·
I maintainer di solito rispondono entro 1 giorno
-
agent-review-finding chore
Difficoltà 2/5 Mezza giornata Idoneità per principianti 78/100
jordansmall/spindrift#4497 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
bug from-studio
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
esengine/DeepSeek-Reasonix#12044 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 82/100