Temporal workflow/worker/activities in typescript and worker/activities in python

Community Support
1

Hey,

We have a use case where we have workflow and activities running on a worker written in typescript sdk and also have another activity which needs to be in python for which we have created a worker in python (and different task queue).

  1. While creating the python worker, I did not specify the workflow (since only ts worker can handle workflow tasks). Is this okay or do i need to specify the workflow in python worker as well?

  2. Since the workflow worker is in typescript, I had to register the python activity with the typescript worker which I did by doing something similar (Namespace: workflow | Temporal TypeScript SDK API Reference) and setting the task queue for python/typescript activities via ActivityOptions. However when running the workflow, my activities are either getting run on the python task queue or the typescript task queue which is causing the activities to fail. I understand its difficult to give a solution just based on that info but any ideas what I might be missing?

2

Ok, just make sure it’s not on a task queue any TS activities are also on.

You wouldn’t really register it on the worker. You could stub out the type though.

Just make sure that activities don’t share queues. You can’t have different activities on different workers but with the same task queue name. Here is an example of a Go workflow calling a Python activity (that just happens to share a task queue name because Go side is workflow only and Python side is activity only, but different task queues would make sense).

3

Thanks for that. Will the activity worker show up in temporal UI, because I don’t see one? Will the UI only show workflow workers?

4

Worker that only polls activity tasks should also show up on web ui.

Do you see it via:

tctl tq desc --tq <taskqname> --tqt activity

5

Hey @tihomir Yeah I can see it via the tctl command but not in the UI.

@Chad_Retz Thanks for the help. I was able to get it running. The issue was some incorrect variable reference which was setting the incorrect task queue name. Appreciate your help here.

6

I couldn’t make my freedom with taskqueue-names, yet, mostly b/c I’m Go socialized, I guess, where everything should have good defaults. And IMHO it’s not the case, here (right?).

What do you think of this approach: when starting an activity in a WF use the activity‘s unique name as its taskqueue name. Background is: any activity worker needs to know this name anyway. If it’s also the name of the TQ (by default, of course). You can start any subset of activity implementations anytime and get the activities processed, for which you have workers online.

This is just a guess, reading this thread: In the „normal“ scenario a single rouge worker implementing only a subset of activity types can wreak a lot of stability havoc, b/c it gets scheduled tasks it won’t process and then some fail-over must reroute the task to a proper activity worker. Is this true?

Thanks, and sorry for my bad understanding here,
Martin

7

The approach you are providing is functionally correct. We were considering making it a default. The problem with this approach is that it is pretty bad from the resource utilization point of view. Each task queue has an associated thread pool to execute activities. So an application can end up with dozens or even hundreds of such pools sharing a single process resource. Task queues are also not free on the service side. They scale well, but you multiply the number of worker processes by the number of activity types. Which might lead to a very large number of task queues. And all of that in situations when a single queue is enough.

1 Like