Hi, let me describe what I think it's a common case (I've already
experimented it sometimes and know others too):
- A request arrives and it's handled by a worker process.
- There is some memory leak in PKG MEM (or perhaps too few memory
allocated for it).
- The process still can do basic tasks as parsing and so.
- The script creates a dialog and does other operation requiring SHM memory.
- When calling to t_relay() it fails due to non enough PKG mem, so the
transaction is not created.
- Also depending on the memory status it's possible that the process
can not generate a SIP error response (so there is no response).
- The client starts with retransmissions.
- These retransmissions would not match an existing transaction so all
the script process is done again (creating a new dialog and so).
- Again t_relay() fails.
In this case, the dialog statistics show an exorbitant ammount of
dialogs, along with other data retrieved from shared memory.
So what I'm in mind is a new script function to get the current
available PKG mem, so the script can determine not to process the
request and reply (if it can) an error response. This would avoid the
creation of a new dialog, db queries and so on.
A workaround is calling t_newtran() at the beginning of the script,
but it's not a very "polite" solution. So I would prefer a script
funciont "get_pkg_mem()" which return the ammount of bytes available
in PKG MEM. Then I could decide whenever continue or terminate the
request process.
Does it sound feasible and useful? opinions?
Thanks.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>