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


This ticket builds on the problem and remedies of the parent ticket.

I think it would be wise to prevent the ChannelRenderer from allocating more rendering threads to a portlet that is known to be leaking them.




Eric Dalquist
September 15, 2011, 3:27 AM

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.

Andrew Wills
September 16, 2011, 5:36 PM

implements feature described here

Andrew Wills
September 16, 2011, 6:17 PM

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

Currently disabled by default.

Andrew Wills
March 27, 2012, 10:34 PM

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

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



Andrew Wills


Andrew Wills



Estimated End Date



Fix versions