459175 - Automatically close workgroup when the queue size reaches a threshold

Status: RESOLVED FIXED

(support.mozilla.org Graveyard :: Chat, enhancement)

Description

[Matthew Middleton (:zzxc)]

A maximum queue size should be established based on the number of helpers signed in, and the workgroup should close automatically when this maximum threshold is hit.  It should re-open when the queue drops below a lower minimum threshold.

Comment 1

[Matthew Middleton (:zzxc)]

Attachment: Close the queue when maxChats exceeded

This patch makes use of the maxMaxChats preference from bug 471004 to close the queue when the number of chats is higher than the sum of maxChats over all available helpers.  Room monitors can effectively bypass this by setting their own maxChats arbitrarily high.

Other agents can increase the queue limit as well by setting their own maxChats higher than the default, up to maxMaxChats.

Comment 2

[Majken Connor [:Kensie]]

Can I ask about the math? This sounds like no one will be allowed to queue, which is wrong, but I might be interpreting the numbers wrong.

When you say number of chats I'm assuming you mean number of chats with an agent in them as well as those waiting in the queue. This number shouldn't be the sum of the max chats, it should be some multiplier of the max chats which will allow some users to wait in queue for a desired amount of time.

Comment 3

[Matthew Middleton (:zzxc)]

This compares the number of chats waiting in the queue to the agents' maxchats.  So, if there are 4 helpers all with a maxchats of 3, 12 people will be allowed to queue.  Once the queue goes above 12, the workgroup closes.

It would be possible to set this limit as a multiplier of the maxchats rather than maxchats directly.  This would require adding a preference to control the value, with a default of 0 (no limit at all).  Since maxchats is adjustable, helpers can always increase or decrease the queue limit by setting their own maxchats.

Comment 4

[Majken Connor [:Kensie]]

Ok, that obviously makes more sense.

Ideally what we want to do is work the queue numbers so that people are waiting an average amount that we've determined. To oversimplify: 

If chats last an average of 2.5 minutes but we want the average wait time to be 5 min then we would want the queue to close at max chats x 2 and of course if the average chat is 5 min and we want the average wait to be 5 min then we should use 1 to 1 as suggested - though there are probably better formulas for calculating this.

Anyway, unless wait time fluctuates greatly (maybe at release time?) we should probably be ok with a hard coded number for the most part, though a pref later on would probably be useful.

Comment 5

[Matthew Middleton (:zzxc)]

Attachment: Add a queue threshold preference to control behavior

This patch adds a "Queue Threshold" preference to control this behavior.
*When 0, there is no queue limit
*When 100, the queue limit is the sum of each helper's maxChats
*With any other number >0, the queue limit is a percentage of the sum of each helper's maxChats.

For example, if the Queue Threshold is set to 50, then the maximum queue size is half of the sum over all users' maxChats.  The minimum limit allowed is one chat in queue.

This makes a database change which will be executed automatically at the same time as the changes in bug 471004.

Comment 6

[Austin King [:ozten]]

Comment on attachment 371515 [details] [diff] [review]
Add a queue threshold preference to control behavior

Patch looks good. I didn't run it locally, nor test it. Very clean and organized. Some optional feedback:

src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/Workgroup.java 1094
You may want to use Math.round here, Java will coerce an int in unusual ways.
http://mindprod.com/jgloss/division.html

line 1243
Consider adding javadoc with an example
that percent - 1 and greater is percentage to scale max connectins too. Example 200 - 200%,
               invalid percent will be set to 100 (100%).
               
line 1427 Consider pulling out CONSTANTS for these perpared statement indexes
static int FOO_PARAM = 1
...
static int ROOM_IRC_PARAM = 15
static int QUEUE_THRESH_PARAM = 16
etc

Comment 7

[Matthew Middleton (:zzxc)]

Checked in r24245

(In reply to comment #6)
> (From update of attachment 371515 [details] [diff] [review])
> Patch looks good. I didn't run it locally, nor test it. Very clean and
> organized. Some optional feedback:
> 
> src/plugins/fastpath/src/java/org/jivesoftware/xmpp/workgroup/Workgroup.java
> 1094
> You may want to use Math.round here, Java will coerce an int in unusual ways.
> http://mindprod.com/jgloss/division.html

The queue threshold is constrained to be an integer, so floating point division shouldn't be necessary in this case.

> line 1243
> Consider adding javadoc with an example
> that percent - 1 and greater is percentage to scale max connectins too. Example
> 200 - 200%,
>                invalid percent will be set to 100 (100%).

Added.

> line 1427 Consider pulling out CONSTANTS for these perpared statement indexes
> static int FOO_PARAM = 1
> ...
> static int ROOM_IRC_PARAM = 15
> static int QUEUE_THRESH_PARAM = 16
> etc

The existing style is from upstream, this patch just adds an extra field to the statement.