<!-- 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 - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description See comments in this PR, https://github.com/kamailio/kamailio/pull/1437 new features are now implemented in the module `acc_json`
#### Load tested ``` Total 1000000 INVITE calls sent in 2294479 ms at rate of 435/sec Total 1000000 responses received in 2295273 ms at rate of 435/sec:
Detailed responses received: - 200 responses: 1000000 (OK) ------ TOTAL responses: 1000000 (rate=435/sec) ``` You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1440
-- Commit Summary --
* acc_json: adding module
-- File Changes --
M src/Makefile.groups (2) A src/modules/acc_json/Makefile (29) A src/modules/acc_json/acc_json_mod.c (279) A src/modules/acc_json/acc_json_mod.h (42) A src/modules/acc_json/doc/Makefile (4) A src/modules/acc_json/doc/acc_json.xml (42) A src/modules/acc_json/doc/acc_json_admin.xml (299)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1440.patch https://github.com/kamailio/kamailio/pull/1440.diff
Thanks! I am going to merge it and do some small adjustments afterwards.
I will also grant you commit permissions to maintain this module directly, without a need for pull requests. For other modules or parts of Kamailio, pull requests should still be used, to allow the original developer as well as the other developers to review/comment.
Merged #1440.
this is a great addition but i think its restricted in the output. `mqueue` and `syslog` shouldn't be here. the module should emit an event with the json payload as a new pseudo var, and in the script we could the use mqueue, syslog or whatever the integrator/developer wishes to do with json payload.
You can add a modparam to tune its behaviour and act as you want. Each developer is guided mainly by what he/she needs. What you suggest is also interesting to have and iirc it was mentioned in the previous related PR, suggesting that future improvement, which can allow pushing out of kamailio via http or other channel.
Otherwise, generic operations/layers can add delays, e.g., in this case writing first in a pv buffer (private memory), then push it with another operation to mqueue (shared memory) or printed to syslog.
So, bottom line, one implementation doesn't exclude the other, they can co-exist.
Hi, @lazedo, thank for the feedback, we could keep some default provided outputs as "ease of use" default solutions and add a generic PV output or another module API.
I can share my thoughts, using mqueue we can already do routing script operation without blocking the worker process. (reusing an existing pattern in Kamailio) As you have seen I provide an example with HTTP, tests have confirmed that this is very scalable with low latency local HTTP server. (especially with connection reuse recently introduced) I did not test http_async not sure if it can be use in this scenario (I hope), but this would provide another very flexible solution to export using HTTP to anything with fluctuating latency.
@miconda Thank you for the review and few fixes, I will gladly maintain this module and extensively test it shortly.
Great work @jchavanton Glad to see this make it upstream.
Packet Type 1 - load tests
``` Total 2500000 INVITE calls sent in 2522028 ms at rate of 991/sec Total 2500000 responses received in 2522826 ms at rate of 990/sec:
Detailed responses received: - 200 responses: 2500000 (OK) ------ TOTAL responses: 2500000 (rate=990/sec) ```
rsyslog ``` wc -l /var/log/json_acc.log 7500012 /var/log/json_acc.log ``` nsqd ``` nsqd v1.0.0-compat (built w/go1.8) start_time 2018-02-16T22:36:24Z uptime 2h1m51.901973386s
Health: OK
[acc ] depth: 0 be-depth: 0 msgs: 7500012 e2e%: [nsq_to_file ] depth: 7500012 be-depth: 7490012 inflt: 0 def: 0 re-q: 0 timeout: 0 msgs: 7500012 e2e%: ``` voip_perf client ``` ./voip_perf -m INVITE -p 7075 sip:+1??????????@10.10.10.10:5060 \ --interval=1 \ --count=2500000 \ --call-per-second=1000 \ --thread-count=1 \ --timeout 17200 ``` voip_perf server ``` ./voip_perf -p 5072 --trying --ringing --thread-count=4 -d 500 ```
Latency graph showing stable response time 
-
Daniel-Constantin Mierla -
Julien Chavanton
-
lazedo
-
William King