Open ThorbenLindhauer opened 8 years ago
This comment was imported from JIRA and written by user zZ6EdaWhat is this name?
This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
Was this already broken before the refactoring or is it something new?
This comment was imported from JIRA and written by user @ThorbenLindhauer
It's new, before there were no jobs kept between acquisition cycles because the acquisition thread executed everything rejected by the thread pool.
This comment was imported from JIRA and written by user zZ6EdaWhat is this name?
This pseudonym name was generated based on the user name in JIRA to protect the personal data of our JIRA users. You can use this identifier to search for issues by the same reporter.
What is the solution?
This comment was imported from JIRA and written by user @ThorbenLindhauer
One idea I had last Friday: The JobAcquisitionContext that is shared between acquisition cycles has to keep a hard reference to the process engines. So when an engine is unregistered, the reference is not immediately gone. After every acquisition cycle the acquisition thread can check for engines that have been removed and unlock jobs.
This issue was imported from JIRA:
With the improvements made in CAM-4400, in case jobs cannot be submitted to the execution queue they are no longer executed by the acquiring thread but deferred for re-submission in the next acquisition cycle. This essentially means there is a context of acquired-not-yet-executed jobs shared between subsequent job acquisition cycles. However, between two cycles an engine may be unregistered or the job executor may be shut down. In such cases, the currently pending jobs are not unlocked, so when immediately restarting the job executor (or re-registering the engine), some jobs are only re-attempted when the lock expires.
Links: