Date of First Response: 2008-01-21 07:10:07 project_key: SOA Description of problem: In beta2 build, viewing the process diagram (in the jBPM console) of a running process fails. The GUI displays: Error getting diagram info: An exception of type "java.lang.NullPointerException" was thrown. The server.log shows: 14:38:20,355 ERROR [Services] problem closing service 'persistence' org.jbpm.JbpmException: setRollbackOnly was invoked while configuration specifies user managed transactions Version-Release number of selected component: soa-4.2.0.beta2.zip standalone-soa-4.2.0.beta2.zip How reproducible: 100% Steps to Reproduce: 1. Deploy (ant deply) bpm_orchestration2 quickstart 2. In the jBPM console, start an instance of the process 3. Attempt to view the process diagram Actual results: The GUI displays: Error getting diagram info: An exception of type "java.lang.NullPointerException" was thrown. The server.log shows: 14:38:20,355 ERROR [Services] problem closing service 'persistence' org.jbpm.JbpmException: setRollbackOnly was invoked while configuration specifies user managed transactions See the attached screenshot and server.log Expected results: No errors. Additional info: In SOA-253 Tom wrote: "Ok, the error indicates that you are using a wrong configuration for jbpm. You probably invoke setRollbackOnly somewhere in the code of one of your action handlers while your configuration indicates that you are using user managed transactions. Either update the configuration to use container managed transactions or update your actionhandler code to invoke a rollback on the transaction instead of a setRollbackOnly." However, in the beta2 configuration of the embedded and standalone servers, in jbpm.cfg.xml isTransactionEnabled is set to false: <jbpm-context> <service name="persistence"> <factory> <bean class="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory"> <field name="isTransactionEnabled"><false/></field> <field name="isCurrentSessionEnabled"><true/></field> <!--field name="sessionFactoryJndiName"> <string value="java:/myHibSessFactJndiName" /> </field--> </bean> </factory> </service> <service name="tx" factory="org.jbpm.tx.TxServiceFactory" /> <service name="message" factory="org.jbpm.msg.db.DbMessageServiceFactory" /> <service name="scheduler" factory="org.jbpm.scheduler.db.DbSchedulerServiceFactory" /> <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" /> <service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" /> </jbpm-context> The action handler in this quickstart is: package org.jboss.soa.esb.samples.quickstarts.bpm_orchestration2.process_actions; import org.jbpm.graph.def.ActionHandler; import org.jbpm.graph.exe.ExecutionContext; public class MyBPMActionHandler implements ActionHandler { private static final long serialVersionUID = 1L; Long startFrom; public void execute(ExecutionContext exCtx) throws Exception { // Token token = exCtx.getToken(); // ContextInstance context = token.getProcessInstance().getContextInstance(); // Object obj = context.getVariable("counter",token); System.out.println("Very simple BPM Process ActionHandler"); //context.setVariable("counter", counter , token); } }
Link: Added: This issue is related to SOA-249
Link: Added: This issue is related to SOA-253
Link: Added: This issue is related to SOA-343
Link: Added: This issue is related to SOA-344
Attachment: Added: Screenshot-3.png
Attachment: Added: server.log.gz
This is a jBPM issue and *not* an ESB issue. The setRollbackOnly is executed from within jBPM when an error in starting the process occurs. The sequence of events are as follows StartProcessActionListener is catching an error during the startProcess and handling it as follows } catch (Exception ex) { context.setError("Error starting process", ex); return; } jBpmPhaseListener then handles this error state as follows if (jbpmJsfContext.isError()) { log.fine("Context has an error status; setting transaction to roll back"); jbpmJsfContext.getJbpmContext().setRollbackOnly(); }
can someone tell me how jBPM is configured in the platform with respect to transactions. and how this matches the BMT in the console and the CMT in the command executor SLSB ? it took me quite a while to get the BMT console running together with the CMT enterprise beans. not all the combinations are supported.
The best answer is to pull it down and look at the configuration yourself. If you go into the SOA IRC then you will find the link in the title.
As for this particular error, why is jBPM code calling setRollbackOnly if it is explicitly forbidden in this circumstance? Does this mean that the GUI does not support this configuration and it shouldn't be used? (org.jbpm.JbpmException: setRollbackOnly was invoked while configuration specifies user managed transactions) Thanks.
Len, can you try to reproduce this problem on jBPM alone, i.e., with the rest of the platform out of the picture?
Link: Added: This issue depends SOA-270
Len, that quickstart uses the old ESB mechanism which is already being replaced by a standard jBPM deployment mechanism (see JBESB-1401). This replacement will rely on the upload servlet though, so SOA-270 is relevant to it. This issue is now about the way in which the jBPM handles console errors during the start process (setRollbackOnly)
I have updated SOA-343 to reflect the link into JBESB-1401 but it still needs to be assigned to Kurt.
Link: Added: This issue is a dependency of SOA-446
I have changed the summary of this task as it is now misleading. There were a number of issues spawned out of this one, the rest of which have been fixed. This issue is concerned with the exception raised when a flow through the jBPM console code results in a call to setRollbackOnly, as described in the first comment.
Steps to reproduce 1) Take GA bits 2) Start server 3) Go to samples/quickstarts/bpm_orchestartion1 4) Run ant deployProcess 5) Go to the Web console 6) Start process processDefinition2 7) Signal started process instance The following error should be written to web page Error signalling token: An exception of type "org.jbpm.graph.def.DelegationException" was thrown. The message is: unable to resolve property: theBody Closing the database context failed: An exception of type org.jbpm.JbpmException was thrown, with the message: problem closing services {persistence=org.jbpm.JbpmException: setRollbackOnly was invoked while configuration specifies user managed transactions} And the server.log contains stacktrace
I should add that the error from the quickstart, as currently written, is expected as it is not intended to be started without setting that variable. This issue is concerned with how the console handles the processing of that error.
Yes, this is just way how to create artificially the error situation - e.g. exception in jBPM
There's a missing step in the instructions: 3.1. ant deploy (So that the classes used in the process are deployed to the ESB)
Based on a discussion with Tom, I would suggest that the SOA team creates their own SoaPersistenceService. This Service should include the JtaDbPersistenceService implementation of the close method and include the referenced DbPersistenceService close method as well. This method should combine the two methods together and comment out the part of the code that is resulting in this exception: if ((session!=null) && (transaction==null) && (isRollbackOnly())) { throw new JbpmException("setRollbackOnly was invoked while configuration specifies user managed transactions"); } the implementation would consist of two classes. SoaDbPersistenceServiceFactory extending the DbPersistenceServiceFactory and SoaDbPersistenceService extending the DbPersistenceService.
Sorry, but if you are suggesting that it is okay for us to mask the exception then surely you are saying that the exception should not be occurring in the first place. What was the discussion you had with Tom and why is this impossible to fix in jBPM? Why can you not extract that check into another method and override it in the JTA subclass? The ESB team will definitely not make this change in our project so the issue with jBPM will remain as far as we are concerned.
overriding the persistence service is the easiest way to get it fixed. that is separate from who does the work. jbpm's inflexibility in this respect is one of the main reasons why we decided to build the pvm.
Sorry Tom but you did not answer my question :) Why can this not be handled in jBPM through simple OO techniques? Is there a reason why we should not be doing it? Is that why you are choosing not to do it in jBPM? What was the reasoning that went into this decision?
in short, it's backwards compatibility. it took me a long time to get it working for one standard and one enterprise configuration. especially the enterprise was difficult because the console uses BMT and the enterprise beans use CMT. since then a couple of configurations that people specified lead to problem and were very hard to fix.
So what you are saying is that we should never use the console and JTA together. Anyone else using this combination will also face this issue. Not sure where CMT/BMT come into it though, this is all pure jBPM in a very simple configuration. Do you think there is something wrong with the way we are configuring or using jBPM?
something like that... the console was not designed with JTA in mind i managed to get it working with this specific combination of the JtaDbPersistenceService impl, jbpm configs and hibernate configs after a long battle. " Do you think there is something wrong with the way we are configuring or using jBPM? " i just don't know cause that combination has not been tried.
My concern is that you are suggesting a change which you are unwilling to apply to your codebase. This causes alarm bells to ring with me as it also suggests that you are unsure of the change and its effect. As this would impact the users of the ESB project and, more importantly, the SOA platform customers I am unwilling to do this. If this change is safe then we have the option of just applying it to the jBPM SOA branch, after all that is why it exists. If you do not want to move it back into your trunk then that is a decision for your team. I do not feel that the ESB team can be responsible for masking a jBPM issue when the jBPM team appear to be unsure of the consequences of doing so.
The mechanism used to reproduce this issue is different in the current GA release of the platform as starting a process from the console no longer starts the process, it only creates it. Once the process has been started (created) it is now necessary to locate the root token and signal it.
I have gone through the jBPM codebase and there are actually two issues to be fixed - the invalid check in the DbPersistenceService - fixing JtaDbPersistenceService to check the TxService.isRollbackOnly as well as checking the current transaction. To fix these issues the attached patch must be applied. The change to DbPersistenceService adds a protected method which correctly identifies whether a transaction is being managed or not, i.e. whether the base check should be applied. The change to JtaDbPersistenceService provides an implementation of this method for the JTA context and also modifies endJtaTransaction to check the TxService as well as the user transaction.
jBPM code patch
Attachment: Added: patch
Comment on : http://jira.jboss.com/jira/browse/SOA-345#action_12404693 With the GA bits - the problem can be recreated by deploying the process archive (e.g., the jBPM example "simple"), starting the process via the console, and then signalling the proces via the console.
Attachment: Added: jbpm_simple.png
Len, do you mean the GA bits of jBPM 3.2.2? In that case how do you deploy? Using the designer or an ant task?
I was referring to the SOA-P GA bits - and deploying via the designer (JBDS 1.0).
This doesn't appear to be fixed in the BRANCH_3_2_2_SOA_4_2 CVS branch and we're past the SOA 4.2.0 CP01 deadline now. Please could we have a fix timescale?
The patch is committed on BRANCH_3_2_2_SOA_4_2.
The transactions-related bugs are no longer there with SOA 4.2.0 CP02.