[JBoss jBPM] - Re: Design Patterns
by rwallis
1) there is a real persisted wait state (and its set from one minute to 19 days depending on the action taken by the user) but we have been getting stack overflow errors (after running 24/7 for about 2 weeks) and then timers stop working (we have to restart the application server) and this is considered the culprit. Given this, one of our developers doesn't want to use jBPM for batch processing that would require escalation (via a timer) every minute. I however would like to use jBPM because then we could leverage jBPM to create fail/retry logic with nodes and the jBPM console for visibility into the batch processing. (and yes there probably are alternatives to using the same token over in a loop but again thats why this was titled design patterns).
2) In the second part, in its simplest, its a task node to a fork with one transition from the fork going back to the task node and a second transition from the fork going to a different task node. When done manually from the first task node (user signals the transition rather then some external event or a timer) its an easy way to allow for a "Resend" A simple example would be "Supervisory Approval" where tokens comes into a "Processor" task node wHere they transition the token to "Supervisor Approval" but still want the token to remain in their task node in parallel, having the "send for approval" transition go to a fork solves this easily, the token goes back to the "Processor" task node and then also goes to the "Superviosr Approval" task node (with a join at the end of all of this of course). The processor continues to have it as an active task and so does the supervisor, then if the processor has an additional task that needs to be done by the supervisor (but again wants to continue to have the task as well) they simply transition the token to the supervisor task node again. In testing this all works perfectly, and all of the child tokens complete out of the join properly but it does seem that there is a limit to the number of inherited children (like maybe 1000) so if the transitions are manual no problem but if automated with timer then its a problem. The question was asked because there is concern that some "idiot" might want to click the button 1000 times an therefore cause stack overflow to occur, we can put a check in to limit this to something reasonable like 10 times but maybe we shouldn't do this at all...
P.S. sorry about posting initially to the wrong forum.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227613#4227613
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227613
17 years
[JBoss jBPM] - Re: nothing persisting?
by ibivibiv
So, now that I know that the JTA persistance is not committing, can anyone give me a hint as to the why? I'll paste my config and a quick example of a MDB that starts a process that never commits to the database.
| <jbpm-configuration>
|
| <jbpm-context>
| <service name="persistence" factory="org.jbpm.persistence.jta.JtaDbPersistenceServiceFactory" />
| <!--<service name="persistence" factory="org.jbpm.persistence.db.DbPersistenceServiceFactory" />-->
| <service name="message" factory="org.jbpm.msg.jms.JmsMessageServiceFactory" />
| <service name="scheduler" factory="org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory" />
| <service name="tx" factory="org.jbpm.tx.TxServiceFactory" />
| <service name="logging" factory="org.jbpm.logging.db.DbLoggingServiceFactory" />
| <service name="authentication" factory="org.jbpm.security.authentication.DefaultAuthenticationServiceFactory" />
| </jbpm-context>
|
| <!-- use the context class loader -->
| <string name="jbpm.classLoader" value="context" />
|
| <!--
| Note, that the default job executor needs to be overwritten with a null value.
| In the enterprise configuration there should be no job executor.
| Async messaging is there bound to jms and scheduling to ejb timers.
| -->
| <null name="jbpm.job.executor" />
|
| </jbpm-configuration>
|
|
| package com.theplanet.jbpm.messagebeans;
|
| import javax.ejb.ActivationConfigProperty;
| import javax.ejb.MessageDriven;
| import javax.ejb.TransactionManagement;
| import javax.ejb.TransactionManagementType;
| import javax.ejb.TransactionAttribute;
| import javax.ejb.TransactionAttributeType;
| import javax.jms.Message;
| import javax.jms.TextMessage;
| import javax.jms.MessageListener;
|
| import org.jbpm.graph.exe.ProcessInstance;
| import org.jbpm.JbpmConfiguration;
| import org.jbpm.JbpmContext;
|
|
| /**
| * Message-Driven Bean implementation class for: ProcessMDB
| *
| */
| @MessageDriven(name = "ProcessMDB", activationConfig = {
| @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
| @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/ProcessQueue"),
| @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
| @TransactionManagement(TransactionManagementType.CONTAINER)
| @TransactionAttribute(TransactionAttributeType.REQUIRED)
| public class CopyOfProcessMDB implements MessageListener {
|
| /**
| * Default constructor.
| */
| public CopyOfProcessMDB() {
| // TODO Auto-generated constructor stub
| }
|
| /**
| * @see MessageListener#onMessage(Message)
| */
| public void onMessage(Message message) {
|
| JbpmConfiguration jbpmConfig = JbpmConfiguration.getInstance();
| JbpmContext jbpmContext = jbpmConfig.createJbpmContext();
|
| try {
|
| TextMessage txt = (TextMessage) message;
| ProcessInstance processInstance = jbpmContext
| .newProcessInstanceForUpdate("TestProcess");
|
| processInstance.signal();
| jbpmContext.save(processInstance);
|
| } catch (final Exception exc) {
| try {
| exc.printStackTrace();
|
| // jbpmContext.setRollbackOnly(); old stuff when using bean managed
|
| } catch (final Exception e) {
|
| }
| } finally {
| // jbpmContext.close(); same on bean managed
|
| }
|
| }
|
| }
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227607#4227607
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227607
17 years
searching for Tasks even if already assigned (jBPM v4.0.B1)
by SirFrancis
Hi All,
currently I'm evolving jBPM 4 to find out if it is suitable for our
requirements. Now I'm not sure how to meet some requirements.
Here the Situation:
I've a task with an entry in the "candidate-groups", and I'm finding the
task with the "findeTakableTasks" function. After assigning the task to
somebody the task disappears from the "findeTakableTasks" function.
To meet requirement I need a function to see ALL (not finished) tasks
for one group (candidate-groups), even if the task is already assigned
to somebody.
is there a way to retrieve such a list?
And another question is: is there a search function to search for tasks?
I would like to search for special variable with special values or for
tasks in a special status and so on.
Thanks for your reply
sirfrancis
17 years
[JBoss jBPM] - Re: Design Patterns
by kukeltje
First of all, thanks for taking the time to post in the correct forum. In return I should take the time to at least try to answer your question.
1) If there is a real persisted wait-state in this loop, you should not get a stackoverflow.
2) If I understand you correctly, you want to have e.g. a node in one 'leg' of a fork go back to the fork node but as a new loop? That is not advised (though it might work, you could give it a try in a unittest). Using recusive subprocesses can be done.
>From what I read, both questions are related. Maybe it is better to give your functional requirements so we can discuss those and try to find a solution that fits.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227561#4227561
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227561
17 years
[JBoss jBPM] - Design Patterns
by rwallis
Hi I new to the forum but have been using jBPM for a bit now (and loving it). I have a couple "design pattern" questions to ask.
1) Should jBPM be used as a "fancy" server side batch processor/scheduler where the token recurses from one processing node to a decision node and then, based on the decision, back to the processing node using a timer thats set at some interval like 1 minute? Will this cause stack overflow problems eventually? Will this cause the log file to get ridiculously large?
2) What is the practical limit of child token hierarchy levels? In other works if a fork is used to send a token back to the node it came from and parallel another token to a different node (resend algorithm), what limit should be put on the resend (or should this algorithm simply not be used), before the child tokens get to be too many and stack over flow occurs?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227546#4227546
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227546
17 years
[JBoss jBPM] - Instance not of expected entity type -> Flush failed
by Stefan1509
Hi all,
Currently I get the following error message. Does someone knows what goes wrong?
Configuration:
Regards,
Stefan
2009-04-29 15:23:57,968 [server-tomcat-thread-2] ERROR org.jbpm.persistence.db.DbPersistenceService - hibernate flush failed
org.hibernate.HibernateException: instance not of expected entity type: org.jbpm.context.exe.variableinstance.UnpersistableInstance is not a: org.jbpm.context.exe.VariableInstance
at org.hibernate.persister.entity.AbstractEntityPersister.getSubclassEntityPersister(AbstractEntityPersister.java:3663)
at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1374)
at org.hibernate.engine.ForeignKeys.isTransient(ForeignKeys.java:203)
at org.hibernate.event.def.AbstractSaveEventListener.getEntityState(AbstractSaveEventListener.java:535)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:103)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:534)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:526)
at org.hibernate.engine.CascadingAction$5.cascade(CascadingAction.java:241)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:291)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:239)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:319)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:265)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:192)
at org.hibernate.engine.Cascade.cascade(Cascade.java:153)
â¦â¦
2009-04-29 15:23:57,968 [server-tomcat-thread-2] ERROR org.jbpm.svc.Services - problem closing service 'persistence'
org.jbpm.persistence.JbpmPersistenceException: hibernate flush session failed
at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:207)
at org.jbpm.svc.Services.close(Services.java:243)
at org.jbpm.JbpmContext.close(JbpmContext.java:133)
â¦â¦.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4227527#4227527
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4227527
17 years
