Was ist der unterschied zwischen prozessid und taskid

Camunda Platform 7 Topics Camunda Platform 7 Process Engine

Can someone help me with these question.

1. What is the java form of FetchAndLock API? I am using embedded engine in a java app.
2. Whats the difference between ExecutionID and TaskID for a User task?
3. When does a new TaskID get created? e.g. if a user task is retried internally does it retain the same TaskID?
4. If a user task gets completed and the flow goes to next tasks and then loops back to the originally completed user task, will a new TaskID for this second time in the same process instance?
5. Also I have same above query for ExecutionID.
6. When does Camunda commit the task statuses? Does it do it immediately after every task or does wait and makes multiple task updates in a future commits?

1. processEngine().getExternalTaskService() .fetchAndLock(maxTasks, workerId)
2. TaskID refers to data regarding the task (assigness, task name etc.) and is specific to a user task. ExecutionID refers to a current state of the instance - i.e. a Token.
3. TaskID is kept until the task is completed
4. No - a new ID is created each time a task is activated
5. ExecutionID is more complicated - there are a bunch of reasons why a new Exectuion is created. it’s worth reading the docs to fully undetstand. https://docs.camunda.org/manual/latest/user-guide/process-engine/process-engine-concepts/#executions
6. When Camunda commits depends on your model. But basically after a task is completed - if all tokens have moved to an end event or wait state it commits.

Niall, Thanks for the reply. I could not find a way to retrieve the Injected fields (via bpmn) of a External Task. Please suggest.

Had it been a service task with java delegation, I could have retreived injected fields. But when the service task is external then I am not sure how to find the injected fields and their values from the worker java call.

What are you using the field injection for?

For an External task I am hoping to define injected field:value pairs such as: start-function : “f1” validate-function : “f2”

compl-function : “f3”

My intention was that when worker gets invoked, it fetches an external task by fetchAndLock. Then it reads the field “start-function” and calls f1. If injecting fields on External task is not possible directly, I can try to inject fields on its ‘start’ Execution Listener and push those values as task variable. So that way I can use the variables in the worker after choosing the task. Let me know if that is ok.

It would be a lot easier if you where to just add them as process variables and ask for them directly when calling fetch and lock. There doesn’t seem to be a need for you to use field injection.

Ok adding them as variable is what i need. But in the BPMN file where do i add the variables. I am planning to use a common delegate/listener for any task and these variables would take different values for different task.
Will using Extension tab help to add variables?

1. TaskID is kept until the task is completed
   @Niall , willll it then be same for external tasks too?

Yes, although things like process instance modification and migration could change the ID

1 Like

Hi @Niall
We want to implement idempotency at external task processing service( while processing external task ) and considering taskId as a candidate for unique id which will be remembered across multiple retries( from external task processing through pull mechanism )
Is it the correct choice to handle scenarios like ?-

1. External task service fetches a task and processes , and fails to invoke complete on that task, and later fetches the same task and reprocesses it ( but should detect that it has earlier processed it based on remembered taskID )

• Article
• 03/18/2022
• 2 minutes to read

Each process running in Windows is assigned a unique decimal number called the process ID (PID). This number is used in a number of ways, for example to specify the process when attaching a debugger to it.

This topic describes how you can determine the PID for a given app using Task Manager, the tasklist Windows command, the TList utility, the PowerShell Get-Process command, or the debugger.

Task Manager

Task Manager can be opened in a number of ways, but the simplest is to select Ctrl+Alt+Delete, and then select Task Manager.

In Windows, first click More details to expand the information displayed. From the Processes tab, select Details to see the process ID listed in the PID column.

Click on any column name to sort. You can right click a process name to see more options for a process.

Some kernel errors may cause delays in Task Manager's graphical interface.

The tasklist command

Use the built in Windows tasklist command from a command prompt to display all processes, their PIDs, and a variety of other details.

Use tasklist /? to display command line help.

TList utility

Task List Viewer (TList), or tlist.exe, is a command-line utility that displays the list of tasks, or user-mode processes, currently running on the local computer. TList is included in the Debugging Tools for Windows. For information on how to download and install the debugging tools, see Download Debugging Tools for Windows.

If you installed the Windows Driver Kit in the default directory on a 64 bit PC, the debugging tools are located here:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\

When you run TList from the command prompt, it will display a list of all the user-mode processes in memory with a unique PID number. For each process, it shows the PID, process name, and, if the process has a window, the title of that window.

For more information, see TList.

The .tlist debugger command

If there's already a user-mode debugger running on the system in question, the .tlist (List Process IDs) command will display a list of all PIDs on that system.

PowerShell Get-Process command

To work with automation scripts, use the Get-Process PowerShell command. Specify a specific process name, to see the process ID for that process.

For more information, see Get-Process.

Additional resources

To learn more about Windows internals (including memory usage, context, threads, and processes), review additional resources, such as Windows Internals by Mark Russinovich, David Solomon, and Alex Ionescu.

I got the answer here on stackoverflow. It states that if we run a program on Linux that contains the libc libuClibc-0.9.30.1.so (1). Basically an older version of libc then thread created will have different PID as shown below

and I tried to run this program with a linux that contains the libc from ubuntu libc6 (2) i.e newer version of libc then Thread created will have the same PID as the process.

And the libc (2) use NPTL ("Native posix thread library") implementation of pthread

According to the linuxthreads FAQ (in J.3 answer):

each thread is really a distinct process with a distinct PID, and signals sent to the PID of a thread can only be handled by that thread

So in the old libc which use linuxthreads implementation, each thread has its distinct PID

In the new libc version which use NPTL implementation, all threads has the same PID of the main process.

The NPTL was developed by redhat team. and according to the redhat NPTL document: One of the problems which are solved in the NPTL implementation is:

Each thread having a different process ID causes compatibility problems with other POSIX thread implementations. This is in part a moot point since signals can't be used very well but is still noticeable

And that explain this issue.

I am using the new libc version that contains the NPTL ("Native posix thread library") implementation of pthread.