Hi Robert,
At a minimum, could the semantics of the job executor be such that the order in which jobs are acquired is the order they fall due. I would gladly swallow the (minor) overhead of an order by construct for predictable job execution.

In my use cases of a shared engine, I have some processes which ideally should be quite timely, whereas others can execute in their own time. Hence its a frustrating operations experience where when waiting on a time sensitive process to see a recently created less time sensitive process ahead of the pack in execution.

I have noticed in test environment under load that processes can tend to execute in a breadth first rather than depth first manner. Hence rather than finishing a current process instance, ie depth first, the executors may pick up the start of a newer process and start 'expanding' its execution tree. Of course this may be a behaviour unique to certain process patterns... Hence throughput in terms of completed processes is more meaningful that work started in my domain. Thus I would expect an order by clause to bias execution behaviour towards 'depth' first with greater predicability and consistency...

We are closing this ticket as part of our backlog grooming. Reasons:

• It is very unlikely that we will implement this
• We did not receive sufficient evidence that this ticket is important