Activiti

Implement exclusive jobs

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 5.9
  • Component/s: Engine
  • Labels:
    None
  • Number of attachments :
    0

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Daniel Meyer (camunda) added a comment -

Basic hooks already available, most notably the property in the jobs table. No schema changes will be necessary.

Show
Daniel Meyer (camunda) added a comment - Basic hooks already available, most notably the property in the jobs table. No schema changes will be necessary.
Hide
Permalink
Daniel Meyer (camunda) added a comment - - edited

Initial version committed in svn branch ACT-989

Show
Daniel Meyer (camunda) added a comment - - edited Initial version committed in svn branch ACT-989
Hide
Permalink
Daniel Meyer (camunda) added a comment -

Merged into trunk in rev 3078

Show
Daniel Meyer (camunda) added a comment - Merged into trunk in rev 3078
Hide
Permalink
Bernd Ruecker (camunda) added a comment -

From the mail:

>> I just committed a fix which makes jobs exclusive by default.
>> I think this is a good approach also in the interest of the-least-WTF
>> from a user perspective.
>>
>> Jobs can be made non-exclusive by specifying
>> activiti:exclusive="false"
>> on a timer definition or an async task.
>>
>> So an async, non-exclusive service would look like this:
>> <serviceTask .. activiti:async="true" activiti:exclusive="false" />

is this resolved now?

Show
Bernd Ruecker (camunda) added a comment - From the mail: >> I just committed a fix which makes jobs exclusive by default. >> I think this is a good approach also in the interest of the-least-WTF >> from a user perspective. >> >> Jobs can be made non-exclusive by specifying >> activiti:exclusive="false" >> on a timer definition or an async task. >> >> So an async, non-exclusive service would look like this: >> <serviceTask .. activiti:async="true" activiti:exclusive="false" /> is this resolved now?
Hide
Permalink
Bernd Ruecker (camunda) added a comment -

So this are correct examples, right?

<serviceTask ... activiti:async="true" activiti:exclusive="false" />

<timerEventDefinition activiti:exclusive="false">
<timeDuration>PT5M</timeDuration>
</timerEventDefinition>

Show
Bernd Ruecker (camunda) added a comment - So this are correct examples, right? <serviceTask ... activiti:async="true" activiti:exclusive="false" /> <timerEventDefinition activiti:exclusive="false"> <timeDuration>PT5M</timeDuration> </timerEventDefinition>
Hide
Permalink
Daniel Meyer (camunda) added a comment - - edited

The examples are correct but proper documentation in the user guide is still TODO.

Show
Daniel Meyer (camunda) added a comment - - edited The examples are correct but proper documentation in the user guide is still TODO.
Hide
Permalink
Falko Menge (camunda) added a comment -

Currently, there is one Job Acquisition Thread per cluster node, which puts the acquired Jobs into a queue, which is then processed by the worker threads. This queue is of type List<List<String>> with the inner list being a list of exclusive job ids that belong to the same process instance.

New exclusive Jobs that are created, while another exclusive Job is executed, go currently not into the existing exclusive jobs set, but are free to be aquired by any Job Acquisition Thread of the cluster and processed by any worker thread.

Our idea is that a thread immediately locks new exclusive jobs for its cluster node and adds it to the list of exclusive jobs it is currently processing.

This way ActivitiOptimisticLockingExceptions at parallel joins can be completely avoided even in clustered environments.

Show
Falko Menge (camunda) added a comment - Currently, there is one Job Acquisition Thread per cluster node, which puts the acquired Jobs into a queue, which is then processed by the worker threads. This queue is of type List<List<String>> with the inner list being a list of exclusive job ids that belong to the same process instance. New exclusive Jobs that are created, while another exclusive Job is executed, go currently not into the existing exclusive jobs set, but are free to be aquired by any Job Acquisition Thread of the cluster and processed by any worker thread. Our idea is that a thread immediately locks new exclusive jobs for its cluster node and adds it to the list of exclusive jobs it is currently processing. This way ActivitiOptimisticLockingExceptions at parallel joins can be completely avoided even in clustered environments.
Hide
Permalink
Falko Menge (camunda) added a comment -

Another observation:
The aquisition of exclusive jobs uses (too?) many SQL queries and may result in idle threads.

Show
Falko Menge (camunda) added a comment - Another observation: The aquisition of exclusive jobs uses (too?) many SQL queries and may result in idle threads.
Hide
Permalink
Daniel Meyer (camunda) added a comment - - edited

Improving support for exclusive jobs (see Falko's comment above):

http://fisheye.codehaus.org/changelog/activiti/?cs=3144
http://fisheye.codehaus.org/changelog/activiti/?cs=3145
http://fisheye.codehaus.org/changelog/activiti/?cs=3146

Show
Daniel Meyer (camunda) added a comment - - edited Improving support for exclusive jobs (see Falko's comment above): http://fisheye.codehaus.org/changelog/activiti/?cs=3144 http://fisheye.codehaus.org/changelog/activiti/?cs=3145 http://fisheye.codehaus.org/changelog/activiti/?cs=3146
Hide
Permalink
jee.lead added a comment -

Quick question: does it mean that having async=true and (by default) exclusive=true, it's really not asynchronously/parallelly run in multiple threads. Aren't we negating what async provides with setting exclusive default option - could you pls clear this confusion, Thanks.

Show
jee.lead added a comment - Quick question: does it mean that having async=true and (by default) exclusive=true, it's really not asynchronously/parallelly run in multiple threads. Aren't we negating what async provides with setting exclusive default option - could you pls clear this confusion, Thanks.
Hide
Permalink
Daniel Meyer (camunda) added a comment -

implemented and documented

Show
Daniel Meyer (camunda) added a comment - implemented and documented

People

  • Assignee:
    Daniel Meyer (camunda)
    Reporter:
    Daniel Meyer (camunda)
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: