Hide Forgot
Date of First Response: 2010-05-12 11:49:52 Help Desk Ticket Reference: https://enterprise.redhat.com/issue-tracker/464703 Workaround Description: * For records where NAME_ = ' ESB_ASYNC_SIGNAL_VARIABLE_ACTOR_': Remove the <property name="actor" value="FrankSinatra"/> property from the BpmProcessor * For records related to the 'theBody' variable: Ensure that the file content is converted into a String before the value is passed into jBPM, for instance by adding the following action before the BpmProcessor (StartProcessInstanceCommand): <action name="transformFromByteArrayToString" class="org.jboss.soa.esb.actions.converters.ByteArrayToString"> <property name="encoding" value="UTF-8" /> </action> project_key: SOA In order to prevent the jBPM database to keep growing, the jBPM API (GraphSession.deleteProcessInstance) can be called to delete ended process instances. After inspecting the tables, however, there is data which is not cleaned up. This can easily be reproduced with the quickstarts: 1. Run the bpm_orchestration1 quickstart 2. Using the jbpm-console app, delete the ended process instance 3. Inspect the jBPM tables, the following tables hold records which should actually have been deleted: JBPM_VARIABLEINSTANCE JBPM_BYTEARRAY JBPM_BYTEBLOCK Looking at the JBPM_VARIABLEINSTANCE table, there are two types of records left: 1. ESB_ASYNC_SIGNAL_VARIABLE_ACTOR_ (String) variable 2. theBody (ByteArray) variable, which is referencing records in the JBPM_BYTEARRAY and JBPM_BYTEBLOCK table For #1, this variable is being created by the ESB when the 'actor' property on the BpmProcessor is defined, but loses the relation to the token, and will therefore not being cleared up. This needs to be addressed in the ESB code, but a workaround is to not use the 'actor' property. For #2, this comes from how the bpm_orchestrationX quickstarts are set up, starting with a file gateway that kicks of the jBPM process. As the file content is placed as byte array, that's how the 'theBody' variable will be created initially. In the course of the other ESB actions, this variable will be updated by a String representation of the content. Hibernate will, however, not update the initial variable instance, but rather create a new one. To get around this, ensure that the variable type does not change.
Link: Added: This issue depends JBESB-3301
The ESB/jBPM async job will now delete the VariableInstances used as part of that communication, although this can only work when jBPM logging is *not* enabled. The quickstart has also been changed to use a message composer, creating Strings rather than byte[] payloads. Updated in ESB codebase, will be in next merge.
Link: Added: This issue incorporates JBPM-2828
JBPM-2828 fixes the very issue that JBESB-3301 works around: delete the variable instances *iff* logging is not enabled. This could lead to executing duplicate and conflicting delete statements. Is JBESB-3301 still necessary even with jBPM 3.2.9?
Part of the fix will be necessary, for example the change in the quickstart and the reworked deletion of the variables. The only part which may no longer be necessary is the explicit hibernate delete of the variable instance. BTW Where is the SOA issue for JBPM-2828?
The explicit hibernate deletion of the variable instance has now been removed from the ESB codebase.
Link: Removed: This issue incorporates JBPM-2828
Link: Added: This issue related SOA-1995
Verified in CR1
Here is the draft text for the Release Notes: https://jira.jboss.org/browse/JBESB-3301 In order to prevent the jBPM database from growing to unmanageable sizes, the GraphSession.deleteProcessInstance is able to delete ended process instances. However, this functionality was not working correctly, meaning that some legacy data was left "orphaned" in the tables. This happened because only the references to the process execution were removed, not the variables themselves. To fix this problem, variable instances are now deleted if logging is not enabled. If the logging service is enabled, the variable cannot be deleted immediately becauses the new VariableDeleteLog instance holds a reference to the variable. (These records are eventually removed upon process instance deletion.) As a result of this fixed, there are no longer orphaned files in the database.