#### Description
In a scalable `Kamailio` architecture that uses `DMQ` to share dialogs (profiles, essentialy) between the peers, in some cases could make sense to remove dialogs that were created and synced from other peers. Example: If a peer goes down and didn't go up again (or in a feasible time), could make sense to remove its synced dialogs (example: `dmq` used to implement a shared dialog counter per provider).
To allow it, a new function was introduced in `dialog` module: `dlg_remove_dialogs_from_node`.
With the new `event_routes`: `peer-up` and `peer-up`, we can easily use this new function to clean the dialogs based on the peer state.
#### Pre-Submission Checklist
- [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] Code is formatted with `clang-format` using the config file `.clang-format`
from source code folder
- [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:
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4754
-- Commit Summary --
* dialog: add new function dlg_remove_dialogs_from_node
* dialog: update with master
-- File Changes --
M src/modules/dialog/dialog.c (22)
M src/modules/dialog/dlg_dmq.c (82)
M src/modules/dialog/dlg_dmq.h (1)
M src/modules/dialog/dlg_hash.c (2)
M src/modules/dialog/dlg_hash.h (1)
M src/modules/dialog/doc/dialog_admin.xml (40)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4754.patchhttps://github.com/kamailio/kamailio/pull/4754.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4754
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4754(a)github.com>
hb9eue created an issue (kamailio/kamailio#4760)
Hi @miconda and @abalashov
Issue as described in [SR-Users]: All AVP get deleted when a htable entry is added which is to be replicated to a peer via dmq. When dmqreplicate is set to 0 the issue does not happen. The issue is present no matter if the DMQ peer is reachable or not.
Running Kamailio 6.1.2 from the Kamailo Repo for Ubuntu Noble.
Issue was not observed with Kamailio 5.8 not tested with 6.0.
Config to reproduce:
```
modparam("htable", "htable", "custprof=>size=8;autoexpire=3600;dmqreplicate=1")
xlog("L_INFO", "0 testing is not yet set, value: $avp(testing) \n");
$avp(testing) = "I am a value";
xlog("L_INFO", "1 testing has value: $avp(testing) \n");
avp_print();
$sht(custprof=>"HTKEY") = "HTVALUE";
xlog("L_INFO", "2 testing has value: $avp(testing) \n");
avp_print();
xlog("L_INFO", "After avp_print\n");
```
Log Output showing Issue:
```
517228636 INVITE]<script>: 0 testing is not yet set, value: <null>
517228636 INVITE]<script>: 1 testing has value: I am a value
517228636 INVITE]avpops [avpops_impl.c:1333]: ops_print_avp(): p=0x7e27041e94b0, flags=0x0113
517228636 INVITE]avpops [avpops_impl.c:1336]: ops_print_avp(): #011#011#011name=<testing>
517228636 INVITE]avpops [avpops_impl.c:1342]: ops_print_avp(): #011#011#011val_str=<I am a value / 12>
517228636 INVITE]avpops [avpops_impl.c:1333]: ops_print_avp(): p=0x7e27041e7d20, flags=0x0113
[...]
517228636 INVITE]<script>: 2 testing has value: <null>
517228636 INVITE]<script>: After avp_print
```
After: $sht(custprof=>"HTKEY") = "HTVALUE"; there are not a single AVP remaining to be printed.
debug level 3 shows xavp_destroy_list() being called a lot, possibly for each AVP?
-Benoît-
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4760
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4760(a)github.com>
#### Pre-Submission Checklist
- [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] Code is formatted with `clang-format` using the config file `.clang-format`
from source code folder
- [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:
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
This PR adds sampled core route latency telemetry and exposes it via existing
internal statistics, scrapeable through `xhttp_prom`.
### Commit split
1. `core: add sampled route latency telemetry and cfg knob`
- adds route latency event payload and event IDs in core stats path
- emits sampled request/reply route latency observations in receive path
- derives reply method from CSeq and classifies reply status (1xx..6xx/other)
- adds core config parameter `latency_sample_n` (default 1, min 1)
- wires parameter through `cfg_core.{c,h}`, `cfg.y`, `cfg.lex`
- documents core settings in `doc/tutorials/cfg_list/docbook/cfg_core.xml`
2. `kex: register and update route latency histogram stats`
- registers bounded latency counters in `core` stats group as histogram-style
bucket/sum/count series
- request dimensions: `method`
- reply dimensions: `method`, `status_class`
3. `xhttp_prom: export core route latency stats as labeled histogram series`
- maps new core latency counters to Prometheus output with labels
- exports `_bucket`, `_sum`, `_count` families
- maps internal `inf` token to Prometheus `+Inf`
- documents metric families and aggregation guidance in
`src/modules/xhttp_prom/doc/xhttp_prom_admin.xml`
4. `devcontainer: add libxml2-utils for xmllint availability`
- adds `libxml2-utils` for XML validation tooling in the Debian devcontainer
### Runtime behavior and compatibility
- No route-script instrumentation is required.
- No additional hot-path network sends are introduced.
- Latency telemetry generation is tied to `core.latency_cfg_log` printable level.
- `core.latency_sample_n` affects metric sampling only; it does not change
existing latency log messages or thresholds.
- Global request/reply latency views are available by aggregating labeled series
in PromQL; detailed method/status breakdowns remain available.
### Validation performed
- Formatted with repository `.clang-format`.
- Built successfully in Debian devcontainer:
- `make -C src -j4`
### Backport plan
This change is intended for backport to `6.1` and `5.8` after master merge,
using `git cherry-pick -x` per CONTRIBUTING guide.
### AI Disclosure
Parts of this contribution were developed with assistance from an AI coding
assistant. The assistant was used for implementation and documentation
drafting.
All generated content was reviewed, edited, and validated by me before
submission, including:
- code and commit structure review
- formatting checks (`clang-format`)
- local build validation (`make -C src -j4` in Debian devcontainer)
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4747
-- Commit Summary --
* core: add sampled route latency telemetry and cfg knob
* kex: register and update route latency histogram stats
* xhttp_prom: export core route latency stats as labeled histogram series
* devcontainer: add libxml2-utils for xmllint availability
-- File Changes --
M .devcontainer/Dockerfile (3)
M doc/tutorials/cfg_list/docbook/cfg_core.xml (25)
M src/core/cfg.lex (2)
M src/core/cfg.y (3)
M src/core/cfg_core.c (3)
M src/core/cfg_core.h (3)
M src/core/core_stats.h (65)
M src/core/receive.c (39)
M src/modules/kex/core_stats.c (245)
M src/modules/xhttp_prom/doc/xhttp_prom_admin.xml (32)
M src/modules/xhttp_prom/prom.c (150)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4747.patchhttps://github.com/kama…
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4747
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4747(a)github.com>
…ith 1 or 2 characters according to RFC 1123
<!-- 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] Code is formatted with `clang-format` using the config file `.clang-format`
from source code folder
- [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] Small bug fix (non-breaking change which fixes an issue)
- [ ] 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 -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
day number may be encoded with 1 or 2 characters according to RFC 1123
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4761
-- Commit Summary --
* - parser: enhanced RFC 1123 date parsing, day number may be encoded with 1 or 2 characters according to RFC 1123
-- File Changes --
M src/core/parser/parse_date.c (19)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4761.patchhttps://github.com/kamailio/kamailio/pull/4761.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4761
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4761(a)github.com>
<!-- 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)
- [ ] Code is formatted with `clang-format` using the config file `.clang-format`
from source code folder
- [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] Small bug fix (non-breaking change which fixes an issue)
- [ ] 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
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4758
-- Commit Summary --
* sqlops: Fix format for return code 3 in docs
-- File Changes --
M src/modules/sqlops/doc/sqlops_admin.xml (8)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4758.patchhttps://github.com/kamailio/kamailio/pull/4758.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4758
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4758(a)github.com>
That infuriatingly simple, yet addictive, mobile game that took the world by storm for a brief, glorious period? It might be nostalgic to think back on a time when something so basic could captivate millions. While the original was pulled from app stores, its legacy lives on. And yes, you can still experience the maddening joy online, for example, at Flappy Bird.
This isn't about glorifying the frustration, but about approaching this little game with a new perspective – one that focuses on understanding its mechanics and finding a weird sort of zen within the flapping chaos.
https://iogamesweb.com/flappy-bird
The Gameplay: A Crash Course in Futility
The premise is absurdly simple: you control a tiny bird (of questionable aerodynamic design) and must navigate it through a series of randomly generated green pipes. Tapping the screen causes the bird to flap its wings, propelling it upwards. The goal is to avoid hitting the pipes – any contact results in instant and humiliating death.
The screen scrolls continuously, so you can't pause to strategize. The distance between the pipes varies, demanding constant adjustments and split-second decisions. It's a game of reflexes, timing, and a healthy dose of luck. Really, that's it. No power-ups, no story, just pure, unadulterated flapping.
Turning Frustration into Fun: Some (Potentially) Helpful Tips
Okay, "fun" might be a strong word, but these tips might at least mitigate the rage:
Tap, Don't Mash: This is crucial. Avoid frantically tapping the screen. Instead, focus on controlled, rhythmic taps. Small, precise bursts of flapping are often more effective than trying to skyrocket your bird to victory.
Short Bursts Are Your Friend: Don't hold down your finger. Short, controlled taps are essential for navigating tight spaces. Think of it as micro-adjustments rather than dramatic flight maneuvers.
Practice Makes (Slightly Less) Imperfect: No, you won't become a Flappy Bird master. But repetition will help you develop muscle memory and improve your timing. Don't expect miracles, but you'll likely see gradual improvement.
Find Your Rhythm: Everyone has a slightly different tapping style. Experiment to find a rhythm that feels comfortable and allows you to react quickly. Some people prefer a faster, more aggressive approach, while others favor a slower, more deliberate style.
Embrace the Absurdity: Honestly, the best tip is to not take it too seriously. It's a silly game about a bird that can't fly very well. Laugh at your failures, celebrate your small victories, and remember that it's just a game. Maybe put on some calming music. Or some death metal. Whatever helps you channel the frustration into something... productive?
Conclusion: Flappy Bird and the Pursuit of Pointless Perfection
Flappy Bird might seem like a relic of a bygone era, but it still offers a unique and oddly compelling gaming experience. It's a testament to how simple mechanics, combined with a healthy dose of difficulty, can create something strangely addictive. So, the next time you're looking for a quick, infuriatingly fun distraction, give it another try. Just remember to breathe, and maybe have a stress ball handy.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#100 - Assignment operators don't work
User who did this - Alex Hermann (axlh)
http://sip-router.org/tracker/index.php?do=details&task_id=100
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.