4

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.

  • 1
    I have proved it Nuno, I have updated my question with the test I ran to prove it. – Saurabh Gangwar Sep 26 '17 at 15:21
  • Thanks - as it was before it sounded like speculation :) – Nuno Linhares Sep 26 '17 at 15:30
3

The idea is that the lifetime of those “ready made” Core Service clients is managed for you by the system and hence you don’t have to (read: should not) dispose them yourself.

If you can prove that the system is not properly managing the lifetime, I recommend to report this to SDL Customer Support.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.