Mrtvi zank u petlji događaja: kako izbjeći i riješiti problem

U svijetu Node.js‑a i drugih event‑loop baziranih platformi, asinhroni rukovatelji (handlers) često moraju komunicirati s drugim servisima. Kad se jedan rukovatelj odluči poslati HTTP zahtjev natrag svom vlastitom servisu, može se pojaviti problem koji se naziva mrtvi zank u petlji događaja (event‑loop deadlock). Ovaj članak detaljno razlaže kako prepoznati takav scenarij, kako ga reproducirati u kontroliranom okruženju i, najvažnije, kako ga riješiti.

Što je mrtvi zank u petlji događaja?

Event‑loop je osnova za upravljanje asinhronom operacijom u Node.js‑u. On se oslanja na event queue i task queue kako bi obradio callback funkcije. Mrtvi zank nastaje kada se petlja ne može nastaviti jer je blokirana od strane operacije koja je sama u sebi blokira. U kontekstu HTTP zahtjeva, to se događa kada rukovatelj čekanje na odgovor iz iste aplikacije, a ta aplikacija je u stanju da ne obradi novi zahtjev dok ne završi trenutni.

Kako prepoznati mrtvi zank?

• Visoka latencija ili zamrzavanje – aplikacija reagira sporije ili se čini da se „zamrzne“ tijekom paralelnih operacija.
• Neobjašnjen rast broja aktivnih tokova – u profiliranju vidite da se broj aktivnih tokova ne smanjuje, što ukazuje na blokiranje.
• Logovi s ponovljenim timeout‑ima – kada se zahtjevi vrate na isti port, timeout‑i se pojavljuju češće.

Reprodukcija problema

Za demonstraciju, uzmimo jednostavan Express server koji ima dva rute:

app.get('/data', async (req, res) => {
  const response = await fetch('http://localhost:3000/data');
  const data = await response.json();
  res.json(data);
});
app.get('/data', (req, res) => {
  res.json({ message: 'Hello' });
});

Ovdje prvi rukovatelj (handler) za /data šalje zahtjev na isti /data endpoint. Ako se pokrene više instanci ovog handlera istovremeno, event‑loop će se blokirati jer se čeka na odgovor koji se ne može dobiti dok se ne završi trenutni zahtjev.

Kako otkloniti mrtvi zank?

• Izbjegavajte rekurzivne HTTP pozive – umjesto toga, izradite internu funkciju koja vrši logiku i pozovite je iz oba handlera.
• Koristite async/await s Promise.all – to omogućuje paralelno izvršavanje bez blokiranja event‑loopa.
• Implementirajte timeout i retry mehanizme – to sprječava da se zahtjev zadrži predugo.
• Izolirajte servisne pozive u zasebne mikroservise – time se smanjuje mogućnost međusobnog blokiranja.
• Koristite profiliranje (npr. clinic.js) kako biste vizualno pratili gdje se petlja blokira.

Primjer rješenja

Umjesto da šaljemo HTTP zahtjev unutar handlera, možemo izvući zajedničku logiku u zasebnu funkciju:

async function getData() {
  return { message: 'Hello' };
}

app.get('/data', async (req, res) => {
  const data = await getData();
  res.json(data);
});

app.get('/internal', async (req, res) => {
  const data = await getData();
  res.json(data);
});

Ovaj pristup eliminira potrebu za HTTP‑om unutar iste petlje i sprječava mrtvi zank.

Zaključak

Mrtvi zank u petlji događaja je čest problem kada se asinhroni rukovatelji preklapaju s vlastitim servisnim pozivima. Prepoznajte znakove, reproducirajte u kontroliranom okruženju i primijenite preporučene tehnike kako biste osigurali da vaša aplikacija ostane responzivna i skalabilna.