Bug 779582 (SOA-1956)

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.