I noticed, while implementing a External Activity
of a Workflow Process
in c#; I get these "Ready Made" client objects (CoreServiceClient
, StreamUploadClient
and StreamDownloadClient
), which are already initialed. These clients are exposed as properties from the base ExternalActivity
class, so one can use them to interact with Tridion.
But I don't see any method from base class to dispose/close those objects. Which means the client objects remains alive even after the activity is finished.
Questions:
- Is there a function to dispose/close those clients once a
External Activity
is finished, If not; is it safe to close those clients in the activity code itself? - How does the active client objects are handled by Tridion once the
External Activity
is over?
UPDATE: I run a quick test to prove "client objects remains alive even after the activity is finished (and probably before the objects are garbage collected by .net core)":
I created a workflow process definition with 3 External Activities.
Set the throttling configuration for the coreservice as:
<serviceThrottling maxConcurrentSessions="100" maxConcurrentCalls="16" />
Update the workflow setting to have single thread to execute External Activities.
I started workflows processes (using the definition) by a C# coreservice script. The script implements a for loop (for count 40) and start workflows one by one on different bundles.
Everytime after finishing the 33rd workflow successfully, the CMS goes un-responsive. That means the test created {Total number of Process} * {External Activities in Workflow Definition} number of Coreservice Instances before CMS(or coreservice) becomes un-responsive, In our case 33*3 =99.
Now when the total number of CoreService Instances cross this limit 100 (as mentioned above in configuration) in 34th workflow, the coreservice gets throttled. Since the for loop in script is quick and .net core doesn't get time to clean the Coreservice Objects the active object count increase with every workflow process(I assume) and eventually crosses the max allowed limit in config. So it proves the Coreservice Objects remain active after an activity finishes.
I also checked the objects for null in the last line of activity code and the objects were available there.