rennykoshy left a comment (kamailio/kamailio#4603)
I wouldn't say that at all... It isn't Kamailio's "fault" that the db is down.
But I tend to advocate for a "defense in layers" approach - i.e. if the DB is
slow, a back-pressure triggered circuit-breaker pattern of some sort, that
drops the failed txn's so that "the show can go on". So if Kamailio _could
potentially protect itself_ against a DB that is down, it's a better experience
for every carrier or system that is talking to that Kamailio instance.
That said, I am not suggesting that scalability should be infinite, rather that
in a scaleable mission critical system, we should see the blocking of
Kamailio's core workers by a single rogue client, as a potential vulnerability.
The semantics of the defense mechanism is obviously the designer's call, but to
say that Kamailio should "trust" EVAPI clients to behave well seems to be a
stretch.
In fact, for your example, I do this in our our core switching software (not
Kamailio) where DB txn's are executed in a separate worker pool and we have (a)
timeouts, (b) a watchdog thread, and (c) hard queue limits (three layers of
defense) against misbehaved DB txns.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4603#issuecomment-3965041117
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4603/[email protected]>
_______________________________________________
Kamailio - Development Mailing List -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the
sender!
