Created attachment 815708 [details] server log Description of problem: When I want to get a task instance info via JMS API, I won't receive the response because there is an exception on the server side. GenericJDBCException: could not initialize a collection: [org.jbpm.services.task.impl.model.TaskImpl.names#10] .... Caused by: org.postgresql.util.PSQLException: Large Objects may not be used in auto-commit mode. There was the same issue BZ 971376 with JBPM engine itself which was considered to not be a bug and might help you to find the problem. How to reproduce: 1. Install BPMS 6.0.0.ER4 with EAP 6.1.0 and configure it to use PostgreSQL 9.2 2. Create simple BPMN process defition containing a single human task 3. Start a process instance of previous definition 4. Get task instance info via JMS API, use new JaxbCommandsRequest(new GetTaskCommand(taskId)); to send 5. See the exceptions in server log
Hi Ivo, if BZ 971376 wasn't a bug, this shoudn't be a bug. I'm assigning Marco to the task because it's realted with the JMS endpoint. But it really seems that it is the same as the BZ 971376
Hi Mauricio, but this issue is on the server side, there must be some code which is not performed within a transaction if I well understand the cause.
This is a human-task issue: the problem is that the human-task returns an entity -- that is using the underlying hibernate (collection) classes. Because hibernate uses lazy initialization, some of these collections have *not yet* been initialized (filled with their values) at the time that the entity has been returned by the TaskService to the JMS api. Unfortunately, the human-task engine doesn't include logic to deal with this situation because it treats the entity (TaskImpl) that it returns as an API object. The human-task architecture basically incorrectly assumes that once it's retrieved an entity and executed its internal business logic, it can then close the transaction: this is incorrect because the entity objects themselves are returned to the users and thus are susceptible to transaction and entity manager state. In BRMS 5.x, we could deal with this within human-task code itself because the external interfaces (mina, hornetq) were part of the human-task component. In BZ 852044 (see below), we ended up extending the scope of transactions in HT to around all serialization actions. (This same issue was also present in BRMS 5.x for which we ended up having to put transactions around a number of query operations in order to serialize the return object before ending the transactions, see https://bugzilla.redhat.com/show_bug.cgi?id=852044 ) Unfortunately, human-task no longer has an external interface, which means that I now have to fix a problem in the *JMS api* that is a result of the problematic architecture in human-task! I've already fixed this problem once! And I'm fixing it again?!? Something doesn't make sense here..
Fixed: 6.0.x: https://github.com/droolsjbpm/droolsjbpm-integration/commit/0ef3686f94a59c06812f89f9d16fdf9d63505d8a https://github.com/droolsjbpm/jbpm/commit/9c091729abda9f9a04d9d1cf38c8d9f4063d0a8e https://github.com/droolsjbpm/jbpm/commit/3aa868e0d9d5174a53f5165a338c8bbba1452736 master: https://github.com/droolsjbpm/droolsjbpm-integration/commit/c6f98540ae9a9e2ddc41db247833d1e3444a6071 https://github.com/droolsjbpm/jbpm/commit/3c70de0e8bc178a9e8385764d7edee3cdae04cf7 https://github.com/droolsjbpm/jbpm/commit/1885a1c07bf9639e59175662ac6051d5e8eab0b7
I have to return this bug due to the same issue with REST API. I noticed that the issue appears only when I want to get task instance info. It's this method taskId what I call remotely https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/kie-remote/kie-services-remote/src/main/java/org/kie/services/remote/rest/TaskResource.java#L168
Fixed: 6.0.x: https://github.com/droolsjbpm/droolsjbpm-integration/commit/a8c1e0a4 https://github.com/droolsjbpm/jbpm/commit/df78e14e master: https://github.com/droolsjbpm/droolsjbpm-integration/commit/79b64b42 https://github.com/droolsjbpm/jbpm/commit/1f5634b3 The above commits were the last touches: a lot of the ground work was actually done by Maciej's partial rewrite of human-task, which made fixing this much, much, much easier. Maciej's rewrite can be found here: 6.0.x: https://github.com/droolsjbpm/jbpm/commit/cc430e3c master: https://github.com/droolsjbpm/jbpm/commit/6ecf49b7
Verified in BPMS 6.0.0.CR1