Hide Forgot
Affects: Release Notes Date of First Response: 2009-11-09 08:23:28 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/362213 project_key: SOA org.jbpm.JbpmConfiguration.java: ===== synchronized void popJbpmConfiguration() { getJbpmConfigurationStack().remove(this); } ===== List.remove() can break ordering in the jbpmConfigurationStack, then eventually getCurrentJbpmConfiguration() will return an wrong jbpmConfiguration instance. (List.remove(java.lang.Object) behaves like FIFO if there are multiple elements which refer the same object) On the other hand, popJbpmContext() pops properly. ===== void popJbpmContext(JbpmContext jbpmContext) { List stack = getJbpmContextStack(); int size = stack.size(); if (size == 0) { ... } else if (jbpmContext != stack.remove(size - 1)) { ... } } =====
Link: Added: This issue incorporates JBPM-2630
This is a candidate for SOA 4.3.0 CP03.
Resolving platform issue as project peer JBPM-2630 has been resolved.
Please review the following draft text added to the Resolved Issues section of the Release Notes: https://jira.jboss.org/jira/browse/JBPM-2630 Previously, the JbpmConfiguration.popJbpmConfiguration() method did not implement "pop" operations correctly. As a consequence, jBPM configurations were being removed from thread-local lists incorrectly in a "First In, First Out" (FIFO) order. To resolve this issue, org.jbpm.JbpmConfiguration.java has been changed. As a result, jBPM configuration lists are now removed from the thread-local list in the correct LIFO order.
> As a consequence, jBPM configurations were being removed from > thread-local lists incorrectly in a "First In, First Out" (FIFO) order. To be precise, They were removed in FIFO order when there are multiple elements which refer the same object. Thanks,
Thank you. Your fast response is greatly appreciated. I have amended the release notes as per your recommendation.
popJbpmConfiguration() has been copied from context pop including comments that are invalid for configurations: ==== log.warn(this + " was not found in thread-local stack;" + "do not access JbpmContext instances from multiple threads"); ==== log.warn(this + " was not closed in reverse creation order;" + " check your try-finally clauses around JbpmContext blocks"); ====
In the previous comment to this JIRA I used a word "comments" that is misleading. "log messages" would have been better.
The log messages are valid. Each time a JbpmContext is pushed/popped, the corresponding JbpmConfiguration is also pushed/popped so that method JbpmContext.getCurrentJbpmContext() can be implemented. There is no other scenario for pushing/popping JbpmConfigurations. If a JbpmConfiguration is not present in the thread-local stack, this is most likely because the JbpmContext was closed in a thread where it wasn't created, hence the warning. JbpmContext is not designed for access from multiple threads. Since no change is needed, can this issue still go into CP03?
As requested by Martin V, I reviewed and improved the warnings logged when closing a JbpmContext in unstructured manner or from another thread. Additionally, I wrote a test to check that unstructured JbpmContext close() operations succeed despite the warning.