[BUG] ManagedRequestPipeline.close() leaves in-flight request futures pending forever
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- java
- Ambito
- backend, distributed-systems
Direzione di ricerca
Start with base-rpc/base-rpc-client/src/main/java/org/apache/bifromq/baserpc/client/ManagedRequestPipeline.java and compare close() with onStreamError(), especially how preflightTaskQueue and inflightTaskQueue are cancelled. Verify that closing a pipeline completes both unsent and already-sent request futures, using the full client/server RPC stack or the in-process transport reproduction described in the issue.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Environment
- BiFroMQ
4.0.0/main @ eef5e3af - Module:
base-rpc/base-rpc-client - File:
base-rpc/base-rpc-client/src/main/java/org/apache/bifromq/baserpc/client/ManagedRequestPipeline.java(close())
Summary
close() cancels only preflightTaskQueue (requests not yet sent). It never touches inflightTaskQueue (sent, awaiting a response). After super.close() disposes the stream, responses can never arrive and onStreamError() — the only path that calls cancelInflightTasks() — will not fire again, so the futures of already-sent requests never complete. Callers on the direct (non-batched) query/execute path hang forever; the batched path is only saved by Batcher's orTimeout(maxBurstLatency) fallback.
Pipelines are replaced via old.close() on store→server route changes, so one range migration with a query in flight triggers this.
Suggested fix
Abort in-flight tasks on close, mirroring onStreamError:
if (isClosed.compareAndSet(false, true)) {
super.close();
meter.recordCount(RPCMetric.ReqPipelineCompleteCount);
cancelPreflightTasks(new RequestAbortException("Pipeline has closed"));
cancelInflightTasks(new RequestAbortException("Pipeline has closed"));
}
Verification note
A regression test requires a full RPC stack (client + server + stream disposal); we verified the path statically and in a rolling multi-node deployment (see below). A reproduction using the in-process transport can be provided if useful.
Production validation
A 6-node BifroMQ 4.0.0 cluster (standalone.sh, systemd, mTLS clientAuth=REQUIRE), fronted by a TCP load balancer with 6 backends. Live clients: 3 bridge replicas (MQTT5, $oshare subscribers) and 10 backend service instances (persistent sessions). RocksDB engine, default configuration otherwise.
The fix (plus other changes) was rolled across all six nodes one node at a time (wholesale lib/ replacement, then restart), with a per-node gate (service active, all four ports listening, cluster mesh re-established). Six of six nodes succeeded, zero rollbacks.
Post-deploy checks (all measured after the rollout):
| Check | Result |
|---|---|
| Cluster mesh (inter-node 8898/8899 connections, per node) | 408–417 established on every node |
| Live client connections (3 bridge replicas + 10 backend services over mTLS) | 13/13 reconnected and stable |
| Cross-node delivery end-to-end | publish on one node → bridge (connected elsewhere) consumed it → forwarded (counter 0 → 1) |
| Client-visible protocol smoke | connect / subscribe / publish with QoS 1 all CONNACK 0 / PUBACK 0 |
No non-batched caller hangs were observed in the rollout window; the fix removes the latent path.
- Lingua principale
- Java
- Stelle
- 805
- Fork
- 99
- Merge medio
- 12h 35m
- PR unite (30g)
- 3
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Nessun modello di pull request
- Nessuna 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 apache/bifromq
-
[BUG] KVRangeRestorer leaves the restore future uncompleted when startRestore() throws, permanently wedging the rangeForse già presa @ImDanXie l’ha presa 34 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
[BUG] TopicUtil.isValidTopicFilter accepts "$share/g/" — a shared subscription with an empty filter that can never matchForse già presa @efegokdemir l’ha presa 36 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
[BUG] UTF8Util.isWellFormed inverts the surrogate-pair check: valid non-BMP characters are rejected, lone surrogates acceptedForse già presa @efegokdemir l’ha presa 36 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Inbound and outbound packet-size checks differ, so a QoS 1 message just under MaxUserPayloadBytes is accepted but never delivered (blocks a persistent subscriber)Forse di nuovo libera @abhiramaab l’ha presa 28 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 55/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Tutte le issue di apache/bifromq
Issue simili
-
[BUG] micronaut-serde-oracle-jdbc-json brings a second OJDBC driver onto the runtime classpathForse già presa @ZARAYACH l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
micronaut-projects/micronaut-serialization#1494 · 4 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 2 giorni
-
code-health feature/sync OS/Android QA/Test-Plan-Specified QA/Yes
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
brave/brave-browser#60327 ·
I maintainer di solito rispondono entro 1 giorno
-
Type: Bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
it-at-m/raumreservierung#383 ·
I maintainer di solito rispondono entro 3 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
aws/context-ontology-accelerator#325 ·
I maintainer di solito rispondono entro 1 giorno