Comment 3 for bug 393476

This bug appears to be caused by the number of subscribers from dupes (1000+ in the case of the bug mentioned in bug 386333). I can't check properly, however, because interestingly enough that bug is now timing out completely. I'm working on finding out why.

In the case of the portlet timeout I think the best way to go about fixing it would be to load the subscribers-from-dupes bit of the portlet separately from the direct and also subscribed bits. This is simple enough to do (it's just a case of creating another portlet template to do the same job as what's already there but with different data) and should mean that if there's going to be a timeout it won't bork the portlet completely. It's not a perfect solution, but it's first step as we work to fix the actual problem, which is to do with the handling of large result sets on the server side.