[OpenSIPS-Devel] [opensips] load_balancer module enhancements (#345)

[Sergey KHripchenko]

@bogdan-iancu, thanks for review!
About pt1.
In original approach we cannot 'reset' LB session by just calling lb_reset() since we don't know the resources set used in previous time. Also the original approach is 'provoking' users to change resources set, since despite we don't want them to do so, we asking them to always provide a resources set every call of load_balance() and never tell them that we assume this string(and group by the way) to be constant across LB session.
Maybe we need to update docs? (and enforce it in the code?)

Again. I still like my re-arrangement of existing code. Would you be agree if I'll rewrite load_balance() without ability to modify 'group' and resources set?.

Would you be agree if we will save initial 'resources set' and group(already happens) and completely ignore them for a future subsequent load_balance() calls? This way we allow:
1. lb_reset() to be called without parameters
2. properly maintain safety of our approach - enforce constant group/resources set per LB session.

About pt.4.
The difference between _NEG and original algs is that when we encounter negative capacity for a resource - we skip the corresponding target as a valid target. so for example when all our targets are having negative capacity - original algs force load_balance() to return 'error', but _NEG algs will still work selecting less loaded target. Is it possible to keep both these abilities anyhow?

One more.
Is it possible that global LB configuration (and thus all destinations and resources) could be changed during existing LB sessions thus invalidating our saved group and resources set bit-mask?
(not during the load_balance() call but between them...)
Do we need to worry about it?

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/345#issuecomment-59378236
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20141016/243fadb8/attachment.htm>