Re: [jboss-user] [jBPM] - in jbpm 4.3, timer not firing to leave its state node.
by Tun Mang
Tun Mang [http://community.jboss.org/people/tunmang] replied to the discussion
"in jbpm 4.3, timer not firing to leave its state node."
To view the discussion, visit: http://community.jboss.org/message/554661#554661
--------------------------------------------------------------
Hi HuiSheng:
The following is my jbpm.cfg.xml for jbpm 4.3:
<?xml version="1.0" encoding="UTF-8"?>
<jbpm-configuration>
<import resource="jbpm.default.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.identity.cfg.xml" />
<import resource="jbpm.tx.hibernate.cfg.xml" />
<import resource="jbpm.variable.types.xml" />
<import resource="jbpm.jobexecutor.cfg.xml" />
<import resource="jbpm.businesscalendar.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.mail.templates.examples.xml" />
</jbpm-configuration>
The following is the sequence of our test activities :
(1) deploy the .jpdl.xml which contains the state node associated with a timer :
<?xml version="1.0" encoding="UTF-8"?>
<process name="test_Timer_1">
<start g="270,34,54,49" name="start1">
<transition to="generate-file"/>
</start>
<state g="222,123,147,40" name="generate-file">
<transition g="-71,-15" name="timeout" to="remove-file">
<timer duedate="10 seconds"/>
</transition>
</state>
<state g="222,214,147,40" name="remove-file">
<transition to="end1"/>
</state>
<end g="272,302,48,48" name="end1"></end>
</process>
(2) run the start process instance:
(3) so we assume that the token entered the "generate-file" node and waited more that 10 seconds, but we still only saw 2 entries in the jpbm4_execution table.
(4) then we deploy one more time, and now we saw the "remove-file" activity entry created in the jpbm4_execution table.
There must be something wrong, but we can not figure out from the jbpm cfg related xml files.
Thanks for your help again.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/554661#554661]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
Re: [jboss-user] [jBPM] - [Q] JBPM 4.4 JbpmException
by Michael Wohlfart
Michael Wohlfart [http://community.jboss.org/people/mwohlf] replied to the discussion
"[Q] JBPM 4.4 JbpmException"
To view the discussion, visit: http://community.jboss.org/message/554660#554660
--------------------------------------------------------------
The problem is there is a database session needed if you call some of the methods, especially on the persistent objects like task, execution, process etc.... that's just the nature of mapping objects to a database, it is not a bug...
you can:
* stick with the methods of the services (RepositoryService, IdentityService, etc)
* open/close an environment that manages the session for you (see developers guide section 6.5):
EnvironmentImpl environment = (EnvironmentImpl) ((EnvironmentFactory)processEngine).openEnvironment();
try {
// do yout stuff here
} finally {
environment.close();
}
* create a command that is executed by the process engine (see developers guide section 6.6):
processEngine.execute(new Command() {
public Object execute(Environment env) {
// do your stuff here
return null;
}
});
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/554660#554660]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months
Re: [jboss-user] [Performance Tuning] - Variation in Max Heap size
by Peter Johnson
Peter Johnson [http://community.jboss.org/people/peterj] replied to the discussion
"Variation in Max Heap size"
To view the discussion, visit: http://community.jboss.org/message/554644#554644
--------------------------------------------------------------
An appplication server will always have remote objects, whether you use them directly or not. By default, the RMI code will perform a major collection every minute. The settings in the run scripts change this to every hour. Why every hour? Why not every 30 minutes, or every 24 hours or every week? Where did the recommendation of one hour come from, and what is it based on?
At the very first JBoss World in 2005 I presented a talk on JBoss AS performance tuning, using the SpecJAppServer benchmark to do the analysis. A typical benchmark run included starting the app server, trying a web page or two to make certain things were running correctly, running the benchmark, and then shutting the app server down. The benchmark runs for about 20 minutes. We didn't want the RMI collector to fire off a major collection during the benchmark so we changed the delay to be long enough that it would not interfere with the benchmark - 60 minutes. After that talk, the 60 minute RMI setting appreared in the run scripts.
The 60 minutes suited out benchmark run - it practically guaranteed that there would be no RMI collection during the time the app server was running. So how long do you typically run the app server before restarting it? A week? A month? Longer? Well, that is what you should base the RMI GC settings on, not an arbitrary recommendation of 60 minutes.
Moral of the story: find out why someone recommends a certain setting, then adjust the setting based on your environment and circumstances.
Oh, and by the way, the RMI thread that handles the GC uses System.gc(), so setting DisableExplicitGC will prevent the RMI GC from taking place. However, it is still a good idea to set sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval to a high value to prevent the RMI thread (the one that sleeps for the time interval and then calls Syste,.gc()) from running.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/554644#554644]
Start a new discussion in Performance Tuning at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 5 months