Hi,
Some percentage of requests processed with async_route("REQ_PROCESS", "5") seem to end up with a resumed transaction, though most do. Not sure what the exact percentage is. The ones that don't
Is this due to excessive requests? Is there a limit on internal IPC queue depth? Is it conceptually similar to a generic shared blocking queue internally, along the lines of 'mqueue'? Is there any reasonable way to troubleshoot this?
Thanks!
-- Alex
Hi Alex,
It seems that a part of your e-mail is missing.
Anything unusual regarding the system load? Any errors in the kamailio logs?
Cheers,
Henning
Hi,
No, the message quoted below was the extent of my e-mail. No errors in the logs. It just seems the REQ_PROCESS (or other arbitrary route name) doesn't get called some of the time, at least under load.
-- Alex
Hello,
about the missing part of your email: in the first message, there is "The ones that don't" at the end of first paragraph, which looks like a part of an unfinished phrase
The internal IPC for async_route() is an array of linked lists in shared memory, normally nothing should be lost, but maybe executed too late, when the transaction is gone. Does debug level allow printing warnings? If yes, then there should be warning messages containing ""active transaction not found" in the logs.
How many async workers are configured?
Just for the records, async_task_route() uses socketpair() for internal IPC, which depends on socket buffer size, but only pointer addresses are sent over, so the processing of the tasks should be very slow to get it filled.
Cheers, Daniel
On 07.02.23 06:57, Alex Balashov wrote: