Description of problem:
Using a large database to replicate slow User Interface response timing while ordering a service I found that the UI Worker on 5.5 is leaking threads and growing in memory usage.

I ran through a simple scenario ordering a service 5 times in a row and the memory usage of the UIWorker shot from 355MiB RSS to 714MiB  during that time frame the number of threads grew from 21 to 111 for that worker.  Prior to that, I had ran through the scenario to "prime" any caches and that is most likely why the thread count was already 21 rather than the "typical" 3 threads I can see this worker has when initially started.

Version-Release number of selected component (if applicable):
Tested on 5.5.4.0

How reproducible:
With this large scale database on 5.5.4.0 it is reproducible 

Steps to Reproduce:
1. Navigate to Services -> Catalog
2. Pick an item to order on the service catalog
3. Observe memory and thread count for UIWorker

Actual results:
Thread count grows by 5 when pressing the order button, memory of the work grew by ~24MiB during that time frame as well.

Thread count again grows after clicking on the request after pushing the submit button.  And further grows on pushing the little checkbox to then approve an order.  These further grow the worker by around 20MiB RSS memory as well.

Approving an order also grows memory ~1MiB RSS

Expected results:
Thread count to only temporarily grow if needed and for memory to be reclaimed 

Additional info:


Memory also appears to climb as text is added to the text dialogs for this service as well.  This does not appear to have any thread leakage though.