Hi,
to answer your questions, let me define foreground versus background threads of execution or synchronous versus asynchronous continuations…
If a client initiates a command (eg start process instance or correlate message etc), the command can run either in a blocking client call and thus execute the process fragment in the context of the calling client’s thread of control, or, until a wait state is reached in the process model. A wait state can be tasks such as receive tasks or user tasks, or if a model construct is marked as asynchronous before or after, a wait stae will be reached. When a wait stae is reached, the engine will flush process state to the database. Once process state is flushed to the database, it is persisted and thus will survive server restarts etc. If the process state is flushed to the database due to the model containing an async continuation, then a background thread from the job executor pool will pickup the process from where is was last persisted and continue to the next wait state. When a job executor thread picks up a process fragment to run, it is locked in the database so that in a cluster, only one node will work on the fragment at any time. The lock is actually a lease so that if that node crashes, after the lease has expired, another node in the cluster will be able to work on the same process instance…
While processing the request if camunda dies what will happen to that request . will another camunda will pick up and process or we need to re submit the request ?
If during request processing the node dies before process instance state is flushed to the database, the request will be lost and will need to be retried. An asynchronous continuation will force a flush to the DB and can minimise the probability of this occuring.
while multiple camunda process engines are using same DB , the request submitted to camunda will be processed by only one camunda process engine or all camunda Engines start processing the same request?
Your load balancer should be configured to send requests to one node at a time. In a cluster, the job executor background threads are cluster compatible and will look after themselves.
Process definition has various types of tasks like Message event based task, timer based tasks, service task, external task based on message receive event. while processing these type of event based tasks if camunda instance node was failed, then how to process those failed tasks? we won’t get that same event/request again? what would be the failover scenario?
Process engine nodes are essentially stateless. The DB state is the source of truth. For timer based events, these will run via the job executor. If a job executor thread fails during processing, the system will tend to self recover via retry. With message correlation wher the event is delivered via an external client, you may want to consider at least once message delivery semantics, and idempotency with respect to process and service task implications…
Are we persisting the event itself in database and then executing the tasks?
If your receive task is marked as async after, then essentially yes…
When tasks are created, the task and its details are created in Runtime related tables “ACT_RU_”. what happens to those data if that particular task was completed? will it be still available in runtime data tables until the process instance completes the workflow or everytime when the particular task completed, the details of that specific task will be removed from runtime data table and moved to history tables?
Yes - process state is in the RU_ tables. At each DB checkpoint, eg wait state when process state is flushed to the DB, completed task state will move from RU_ to the Hist_ tables…
Hope this helps,
regards
Rob