alternative command to output dialogs data to file, far much faster than dlg.list
<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [x] New feature (non-breaking change which adds new functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [x] Tested changes locally - [x] Related to issue #2269
#### Description This command can output 100K dialogs in less than a second.
Almost the exact same format as dlg.list, except no using arrays for `variables` and `profiles` since they can have a mixture of values and key / value pairs.
``` { "h_entry": 16383, "h_id": 4428, "ref": 2, "call_id": "ehm839mk6HwtIXfCpluxkNlbDq8H9im2", "from_uri": "sip:voip_perf@147.75.65.147", "to_uri": "sip:12063722016@52.42.112.121", "state": 4, "start_ts": 1585863821, "init_ts": 1585863821, "end_ts": 0, "timeout": 1585885421, "lifetime": 21600, "dflags": 1539, "sflags": 0, "iflags": 0, "caller": { "tag": "KK4KtrhQ--OjGMBNCvpXfKX-tinxQ3EK", "contact": "sip:voip_perf@147.75.65.147:5072;transport=udp", "cseq": "25945", "route_set": "", "socket": "udp:0.0.0.0:5060" }, "callee": { "tag": "jlf1PLBMkC3utNwg-qwdkolYbaMx0no5", "contact": "sip:voip_perf@147.75.65.147:5060;transport=udp", "cseq": "0", "route_set": "", "socket": "udp:0.0.0.0:5060" }, "profiles": { "outbound_call": "" }, "variables": { "foo": "bar" } } ```
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2272
-- Commit Summary --
* dialog: adding dlg.dump
-- File Changes --
M src/modules/dialog/Makefile (15) M src/modules/dialog/dialog.c (155) M src/modules/dialog/doc/dialog_admin.xml (18)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2272.patch https://github.com/kamailio/kamailio/pull/2272.diff
Hopefully we can also optimize JSON-RPC responses to support something that fast and use pipe-lining to make sure memory will never be a concern.
The dialog state can be quite valuable for platform developers, we can imagine many use cases. I understand this ca already be use however it is not fast enough in some cases, seems like it could also be traffic impacting since it is holding a lock.
I think it would be a great improvement to make sure we get very fast and "reliable" JSON-RPC access to its state.
I understand 100K may seem to much, but in some scenarios "broken" traffic can create leaking dialogs and extracting the dialog state is one good way to find out what is happening.
Also it is already slowing down a little bit at 10K and "may" impact traffic slightly. I am not sure I would feel safe about building too much logic around doing many JSON-RPC requests to dialog.list on live servers.
However with such a much faster version I do feel much better doing that.
Is anything particular that jansson offers for this case compared with the internal srjson (which is based on cjson lib), see src/core/utils/srjson.{c,h} ?
Dialog module already uses srjson for profile storage and you can use srjson either with system malloc or internal memory.
Missed this one, I guess I should use it.
Yes, it is preferred to use the included srjson.{c,h} functions, because it doesn't introduce any external dependency.
@jchavanton pushed 1 commit.
7821f5804d0d4c2fdd69b4c5bfa5895d620c6976 dialog: adding dlg.dump
@jchavanton pushed 1 commit.
8b8af03b7de23aa2c1eedbbcf7f8cb5dfcef48bc dialog: adding dlg.dump
done
Thanks, I am fine to merge it with one more remark.
Thinking a bit more about the rpc command name, I would suggest to change it to `dumpfile` or something else to suggest is writing to a file. Actually I would like to have something different that `dump` because other modules use this name to write back to rpc response. We have now a mixture between `list` and `dump` that write back to rpc response, adding a new `dump` with a different type of behaviour will make it incosistent. For example, if we add a similar command to usrloc for writing to a file, the `dump` command is already there. Let's add a name that can be (re-)used to other modules in the future, so we have some consistency from this perspective.
I also hope we can find time to improve dlg.list to be much faster, this was a bigger project ...
Merged #2272 into master.
last modifications and docs tested once more before merging
`dlg.dump` >> `dlg.dump_file` was not updated in the commit message but it was in the docs ...
Not a real concern.
-
Daniel-Constantin Mierla -
Julien Chavanton