workItemByteArray null when persisting WorkItemInfo

[demkezo]

Hi,

We've updated to 5.4.0.CR1 to resolve an this issue: https://community.jboss.org/message/766586#766586. We now have a problem where the WorkItemManager cannot complete our Human task and continue the process. We debugged and found that the workItemByteArray is not being persisted in the DB as it previously was, hence causing an issue when it is being read by the workItemManager.

Can anyone help?

Thanks

Khetha

[swiderski.maciej]

could you provide bit more details? Is this a human task or a custom work item? Would be great if you could provide test case that illustrates this. So far I have not seen this at all but it is very important

Cheers

[demkezo]

We've written our own implementation of the human task. We've been using a snapshot version of 5.4.0 which is dated 2012-06 (yyyy-mm) to run our processes. I noticed that when entering a normal HT, or our own implementation, the workItem be written into the WorkItemInfo table with the workItemByteArray being populated. We upgraded to 5.4.0.CR1 and now find that the workItemByteArray is no longer being populated in the WorkItemInfo table for these tasks. This presents an issue, with our HT, when it is being completed as it's not able to read the workItem from the workItemInfo object where our process is not being continued.

Does this help/make sense?

Regards

Khetha

[swiderski.maciej]

Just tried with two data bases (H2 and postgresql) and default HumanTask work item handler and workiteminfo table has properly set byte array, so can't really see any problem with that and in fact there was no change in that area. If you could provide some test cases that illustrates it it would make it easier to look into that but without being able to reproduce it can't help much here.

HTH

[tcharman]

Hi Maciej

We are using MySQL, I wonder if that behaves differently.  We had this working with an old snapshot of 5.4.0, but it isn't working now.  With org.hibernate set to DEBUG we can see that hibernate has a pointer value for the byte array, and server debugging we can see that the byte array contains data.  But the MySQL general SQL log is showing null.  We're trying to get more logging but we're getting stuck.  Will post more info as we find it.

Tim

[tcharman]

Hi Maciej

The latest is now that the WorkItemInfo is actually being written with the byte array, and deleted a few log lines later, so we don't think that is the real issue.  We are now seeing this:

16:51:17,738 DEBUG [org.hibernate.engine.jdbc.internal.LogicalConnectionImpl] (NioProcessor-7) Aggressively releasing JDBC connection

16:51:17,739 DEBUG [org.hibernate.engine.jdbc.internal.LogicalConnectionImpl] (NioProcessor-7) Releasing JDBC connection

16:51:17,739 DEBUG [org.hibernate.engine.jdbc.internal.LogicalConnectionImpl] (NioProcessor-7) Released JDBC connection

16:51:17,739 DEBUG [org.hibernate.ejb.AbstractEntityManagerImpl] (NioProcessor-7) Looking for a JTA transaction to join

16:51:17,739 WARN  [org.hibernate.ejb.AbstractEntityManagerImpl] (NioProcessor-7) HHH000326: Cannot join transaction: do not override hibernate.transaction.factory_class

We have this in persistence.xml:

      <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" />

Our datasource uses the standard MySQL driver, not the XA driver... could that be the problem?

Thanks

[swiderski.maciej]

Timothy, are you running on JBoss AS7 and use Hibernate4 that comes with AS7? If so take a look here, Marco has written interesting post about potential pitfall with such setup that might help in your case.

HTH

[tcharman]

Yes, we are on AS7 and Hibernate 4.  We followed Marco's recommendations and that seems to remove a bunch of error messages, but now we're running into a couple of oddities when debugging why it still won't work.

Our task handler is meant to be a long running process, which enters a wait state after calling externally.  I believe that the WorkItemInfo table is written prior to hitting the wait state, and on hitting the wait state the bytearray with the work item's state is persisted with an update statement.

Either we see this:

- The WorkItemInfo record is written, the byte array is not written, and on completing the task handler the JPAWorkItemManager reads state out of memory, hits the signalEvent and hangs on synchronisation.

- The WorkItemInfo record is written, the byte array is written, but on completing the task the WorkItemInfo record is already deleted, cannot be retrieved from memory or from DB, and so the process fails.

We continue to debug.

[swiderski.maciej]

thanks for update. what could be worth trying is to see if that is only with your custom ht handler or a generic case for the environment. If you could try with default implementation for ht and evaluation process from jbpm installer to see if problem is there as well. Or simply by running cr1 installer with your mysql data abse...

HTH

[pnj1917]

Hi Maciej,

I'm Namjun who work with Tim and Khetha. What we found was that when we remove the timer task(10min) from our workflow it works fine and workItemByteArray gets updated properly. Originally, we have a timer task just right after begining(start event) in our jBPM workflow.

Do you have any idea if there is any relation between timer task and storing workItemByteArray?

Namjun

[z564808896]

Hi,Timothy.

The same issue occurs in my project, the workItemByteArray is always null after startProcess(),Could you teach me how to solve it?Thanks in advance.

[nitishraj17]

Hi,

I am facing the same issue. The workItemByteArray is saved as null in WorkItemInfo table when I do startProcess.

I am using JBPM 7.6.0.Final on Tomcat 7 Server using bitronix 2.2.1.

Please suggest if there is a fix/workaround to this issue.

Thanks,

Nitish