Task Routing and Media Routing Domain "max calls in queue"

[timo.valimaki@hp.com]

How does Cisco UCCE Task Routing take MRD's max calls in queue setting into account or does it? Seems that at Socialminer level there's limit of 10 000 queuing tasks in total, but if there's multiple MRDs configured and some of those with lower max calls in queue setting and that exceeds, does SocialMiner throttle tasks to that specific MRD and discard request with NOTIFICATION_RATE_LIMITED even if total limit of 10 000 has not been reached yet?

[namahesh]

Hi Timo,

So, it is true that SocialMiner implements throttling of incoming tasks backed by a queue of size 10,000.

However, the throttling in SocialMiner is not specific to any MRD and not influenced by any max calls setting made in MRDs in CCE. It applies overall to all tasks injected across all MRDs, and the allowed rate is a constant 375 tasks per minute.

Any incoming tasks that get throttled (due to the above rate limit) will be backed-up in the queue (of size 10,000).

Hope this answers your question.

Thanks,

Nagendra U M

[timo.valimaki@hp.com]

This answers partially. What happens if there's MRD with task limit of 1,000, 1,000 tasks already queuing in that MRD and there's still room left in SocialMiner's queue (10,000)?

I mean, CCE will not accept new tasks for routing as concurrent task limit has exceeded. Does SocialMiner still accept new tasks for the MRD, polls the MRD for "free slots" and sends the queuing tasks to CCE as soon as CCE gets some queuing tasks routed to agents?

[namahesh]

Hi Timo,

Even in the situation described by you above, SocialMiner will continue accepting new tasks via the REST API and attempts to push them as MR tasks into the MR PG as long as SocialMiner's global throttling limit for all tasks (irrespective of MRDs) is not exceeded.

SocialMiner does not adapt the injection of tasks into MR PG based on whether any specific MRD has free slots or not.

The whole notion of throttling in SocialMiner (and the backing queue behind this throttler) is to protect and offer stable behavior in the case of burst loads that might momentarily exceed the constant throttle.

Thanks,

Nagendra U M

[timo.valimaki@hp.com]

Hi,

Thanks for quick response. Sorry, but I need to ask once more to get this clarified for good:

"SocialMiner will continue accepting new tasks via the REST API and attempts to push them as MR tasks into the MR PG"

-> Will attempt, yes. But MR PG will not accept those until there's room available in MRD.  So, if MR PG bounces 1st attempt, will the task be re-attempted until it will be accepted by MR PG or will it be reported as rejected to caller if the ist attempt fails?

[namahesh]

Hi Timo,

If the MR PG fails to accept a task, it is reported as rejected (state: DISCARDED) to the caller. There is no attempt to re-inject explicitly rejected tasks from SocialMiner.

Thanks,

Nagendra U M

[timo.valimaki@hp.com]

Ok. now it's crystal clear. Thanks!