Dear all,
i have configured realtime (mysql) queues with linear strategy.
How can i configure the sequence using the database?
Thanks and regards,
Davide
Looks like they need to be added in a particular order.
From the doc…
linear: Rings interfaces in the order they are listed in the configuration file. Dynamic members will be rung in the order in which they were added.
If it works as I think, you could modify the internal database within the dialplan.
Set(currentlist=DB(family/key)=${foo})
AGI(resort.php,${currentlist})
Set(DB(family/key)=${foo})
mark*CLI> database show
/Queue/PersistentMembers/7001 : SIP/1001;0;0;SIP/1001;SIP/1001|SIP/3001;0;0;SIP/3001;SIP/3001|SIP/2001;0;0;SIP/2001;SIP/2001
Ok, i thought that using penalty could solve my issue.
So, what is the usage of penalty?
Thanks,
Davide
Penalty is basically useful for wrandom strategy.
snippet from queues.conf
[quote]wrandom - rings random interface, but uses the member’s penalty as a weight
; when calculating their metric. So a member with penalty 0 will have
; a metric somewhere between 0 and 1000, and a member with penalty 1 will
; have a metric between 0 and 2000, and a member with penalty 2 will have
; a metric between 0 and 3000. Please note, if using this strategy, the member
; penalty is not the same as when using other queue strategies. It is ONLY used
; as a weight for calculating metric.[/quote]
–Satish Barot
penalty is valid for most strategies. wradom is actually an outlier.
The way that linear work is that the hashing of the member names is made degenerate, so that there is only one hash bucket. As a result, they are always searched in the order in which they were added. However, when app_queue searches them, it scores them by counting how far down the list they are are and adds on something like 10000 times the penalty. Thus all members with penalty zero will be used before any with penalty 1, even with the linear strategy.
wrandom has a long description of penalties because it doesn’t use them in this way.
Dear David,
thank you for your reply, but it’s not so clear for me.
If i have 4 members (i’m using Mysql DB):
- David -> penalty 3
- Amber -> penalty 2
- Zulu -> penalty 1
- Bob -> penalty 2
How does the linear strategy works?
Thank you very much,
Davide
For the first attempt, I would expect them to be tried in the order:
Z
A, B in the order they are returned by the database
D
For subsequent attempts, it gets more complicated, as it will try to remember where it left off, ignoring the penalties, and I never convinced myself that it does that properly. If Z rang out, I think it will try Z again.
I have just done some tests, and:
Z
A, B in the order they are returned by the database
D
It starts from Z, if Z doesn’t answer it start again from Z (like an infinite loop).
So, onlu Z will ring…
So, i think this a “bug” of Asterisk.
What do you think?
Thanks,
Davide
I think it is a failure to properly explain the algorithm. In general queue doesn’t work in a particularly intuitive way, but it is working as intended.
Each time you go to a timeout, counts as one try. It then waits for the retry time. After that it starts from the beginning with the exception that it remembers its position in the linear order. As you only have one at the lowest penalty, if it is free, it will always be tried first on a retry.
If Z had been unavailable, I believe that A and B should have been alternated.
As noted in my earlier reply, I’m not convinced that the logic that it uses to remember its position in the linear order is right, but, as you only have one lowest penalty member, that is not relevant.
So, my question is: there is any official guide/documentation that explains the behaviour of Queues and Realtime?
Thanks,
Davide
I doubt it. There isn’t much detailed documentation, other than the source code itself, of components that are that old, and also I believe that realtime is third party contributed code.
However, the behaviour you don’t like is actually not specific to realtime. For the case in question, the first reference to the queue causes a request to be made to the database and the results are added into the list of members in the order they are returned by the database. From then on, the behaviour is the same as if you had listed the members in that order in queues.conf. Penalty has no effect on the order at this stage.
When a queue entry is tried, the members are read out in that order and scored based on A*penalty + position, where I think A is 10,000. Only ones potentially eligible at the start of that attempt are included in the list. They are then tried in increasing order of that score until they either get answered or one of them rings out.
If the result is a member ringing out, it waits the retry time then rescores the then available members. In doing so, it tries to take account of where it left off and scores as though it had started with the first position after that point, and wrapped round. At least that is what it is intending to do.