When a portlet begins to leak rendering threads, prevent it from obtaining more threads beyond a configurable number

I added a first pass in trunk at a BlockingQueue that can perform Quality of Service style balancing of which portlet to execute next based on the fnames of the queued portlets. The implementation uses an abstract QualityOfServiceBlockingQueue class which uses a Map of Queues to divide each portlet worker into its own bucket. The concrete implementation buckets the workers by the fname of the portlet and then iterates over the buckets to balance the use of threads across all fnames.

A more complex implementation is needed to have any real value, some ideas are:

• Track the current number of workers for each fname currently executing in the pool.

  • Don't allow any one fname to use more than X% of the max threads value for the pool (50% for example) by skipping it in favor of other fnames with queued workers

• Track the % of workers that have timed out for each fname over the last X executions or Y minutes.

  • If the timeout ration gets above a certain threshold for an fname start skipping it in favor of other fnames with queued workers

The changes were committed to trunk under: https://developer.jasig.org/source/changelog/jasigsvn?cs=24990 Unfortunately the portlet execution code is completely different in 4.0 so I'm not sure how much effort would be involved in a backport.

implements feature described here

Committed revision 25038. (rel-3-2-patches)

Currently disabled by default.

This tech was enabled (by default) for rel-3-2-patches.

There is another sub-JIRA for the enhancement to uP4.