Dynamic activities registration at runtime and worker splitting

Hi,
I’m trying to integrate Temporal in a micro-architecture in a multi-node cloud environment.

  • Is it better, on a single node, to run multiple workers with a unique workflow or one worker with many workflows listeners
  • If a have a workflow named ‘createUser’ which provision the user in many third party, a new third party managed by another entity want’s to subscribe to the user, by declaring an activity, is there any system to dynamically load their activity by a JAR on Temporal and register it in the workflow without the need to my team to modify the existing workflow? (a real example can be Keycloak with a SPI to integrate new behaviours at runtime)
1 Like
  • Is it better, on a single node, to run multiple workers with a unique workflow or one worker with many workflows listeners

We recommend one worker with many workflow types. It is more efficient and allows configuring limits (like a number of parallel executions) for all of them together. In some rare situations, some workflows might require separate limits which might require a separate worker. But it shouldn’t be a default.

No need to load activity types into workflows. Just invoke activities by their string names for those use cases. Here is how to invoke an activity by its name:

 ActivityStub stub =
        Workflow.newUntypedActivityStub(
            ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofMinutes(1)).build());
    stub.execute("activityName", ResultClass.class, args);

Thanks for your answer,
Ok for the first part,
for the second … I only have to set in the workflow the method newUntypedActivityStub instead of registerActivitiesImplementations?
but where is activityName defined ? and can activities be added without restart the worker ?

Worker. registerActivitiesImplementations should be done by the process that hosts activities. Are you looking into dynamic loading of activity implementations into their worker?

The worker that executes the workflow code only doesn’t need to register any activities and it can invoke them through the untyped stub by name without any registration.

1 Like

Yes exactly, I want to load an activity dynamically into the worker

the activity name is the interface name of the activity ?

We don’t have direct support for loading activities into the workers. It should be a pretty reasonable change to expose some sort of a factory that would take activity name and private the implementation. Then you would be able to implement the dynamic loading as an implementation of that factory.

1 Like

It seems very interesting.
Unfortunately, I won’t be able to help with a PR but I will check if this feature will come soon

Filed https://github.com/temporalio/sdk-java/issues/245

Is this behavior can be cloned for workflow as well?

Yes, this is the plan.

Hello friends!
Is this feature available for Go SDK as well? if not, do you have a plan and ETA for this? It will be very helpful for our use cases :))

Thank you!

1 Like

Would you file an issue against Go SDK to get this added?

2 Likes

I think this was not created in the issue tracker. I can do that if still useful as my use case would also be helped with this feature.

Btw, how do you deal with changes in functionality between the various SDK’s? Are they eventually all synchronised to work exactly the same?

Btw, how do you deal with changes in functionality between the various SDK’s? Are they eventually all synchronised to work exactly the same?

Our goal is to eventually have full feature parity among all the SDKs. There is feature parity for the main features already. But some features, mostly around extensions (like interceptors or dynamic activities and workflows) are not available for all SDKs.

1 Like

Thank you. I filed the issue to Go SDK as requested above: Support dynamic activity and workflow implementations · Issue #543 · temporalio/sdk-go · GitHub