[JBoss JIRA] Commented: (JBPM-742) Reimplement JobExecutorServlet as a ServletContextListener
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-742?page=comments#action_12415728 ]
Alejandro Guizar commented on JBPM-742:
---------------------------------------
Undertook this one as part of my "system" testing of the web console without enterprise beans. Worked just fine. JobExecutorServlet was left intact for backwards compatibility.
> Reimplement JobExecutorServlet as a ServletContextListener
> ----------------------------------------------------------
>
> Key: JBPM-742
> URL: http://jira.jboss.com/jira/browse/JBPM-742
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2 alpha 2
> Reporter: Alejandro Guizar
> Assigned To: Alejandro Guizar
> Fix For: jBPM jPDL 3.2.3
>
>
> ServletContextListeners are a viable alternative to servlets for management of the jBPM scheduler/command threads. From the Servlet 2.4 spec, section 10.2:
> >>>
> Servlet event listeners support event notifications for state changes in the ServletContext, HttpSession and ServletRequest objects.
> Servlet context listeners are used to **manage resources** or state held at a JVM level for the application.
> <<<
> Their intent definitely seems to match our purposes.
> Further below:
> >>>
> There may be multiple listener classes listening to each event type.
> <<<
> We could have separate listeners for the scheduler and command executor so that applications may remove either of them in case the related service is not used.
> Section 10.2.2 provides an example. When the application starts up, the listener creates a connection to the database and stores it in the servlet context. Servlets access the connection from the context as needed. When the application shuts down, the listener closes the connection.
> Our listener could start the thread and store it in the servlet context, then stop it using the mechanisms provided by JBPM-741.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Updated: (JBPM-742) Reimplement JobExecutorServlet as a ServletContextListener
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-742?page=all ]
Alejandro Guizar updated JBPM-742:
----------------------------------
Fix Version/s: jBPM jPDL 3.2.3
(was: jBPM 3.3)
> Reimplement JobExecutorServlet as a ServletContextListener
> ----------------------------------------------------------
>
> Key: JBPM-742
> URL: http://jira.jboss.com/jira/browse/JBPM-742
> Project: JBoss jBPM
> Issue Type: Feature Request
> Components: Core Engine
> Affects Versions: jBPM jPDL 3.2 alpha 2
> Reporter: Alejandro Guizar
> Assigned To: Alejandro Guizar
> Fix For: jBPM jPDL 3.2.3
>
>
> ServletContextListeners are a viable alternative to servlets for management of the jBPM scheduler/command threads. From the Servlet 2.4 spec, section 10.2:
> >>>
> Servlet event listeners support event notifications for state changes in the ServletContext, HttpSession and ServletRequest objects.
> Servlet context listeners are used to **manage resources** or state held at a JVM level for the application.
> <<<
> Their intent definitely seems to match our purposes.
> Further below:
> >>>
> There may be multiple listener classes listening to each event type.
> <<<
> We could have separate listeners for the scheduler and command executor so that applications may remove either of them in case the related service is not used.
> Section 10.2.2 provides an example. When the application starts up, the listener creates a connection to the database and stores it in the servlet context. Servlets access the connection from the context as needed. When the application shuts down, the listener closes the connection.
> Our listener could start the thread and store it in the servlet context, then stop it using the mechanisms provided by JBPM-741.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Closed: (JBPM-668) JPDL : Missing name on a transition in a decision make the conditions fail
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-668?page=all ]
Tom Baeyens closed JBPM-668.
----------------------------
Resolution: Deferred
That's becuse of the persistence model. Will be fixed in jPDL 4.
> JPDL : Missing name on a transition in a decision make the conditions fail
> --------------------------------------------------------------------------
>
> Key: JBPM-668
> URL: http://jira.jboss.com/jira/browse/JBPM-668
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1.1
> Reporter: Ephemeris Lappis
> Assigned To: Tom Baeyens
> Priority: Minor
>
> Inside a decision node, if a transition has not a name attribute, the condition is not evaluated as expected.
> For exemple, the following lines work :
> <decision name="decision-x">
> <transition name="t1" to="node-a" />
> <transition name="t2" to="node-b">
> <condition expression="#{...}" />
> </transition>
> </decision>
> If the condition in the second transition matches, this transition is selected as expected.
> But if the name of the transition is removed, the condition result is not correct :
> <decision name="decision-x">
> <transition name="t1" to="node-a" />
> <transition to="node-b">
> <condition expression="#{...}" />
> </transition>
> </decision>
> In this case, the first transition seems to be always selected as default choice...
> The name attribute of a transition seems optional, and no error is produced if it is not present : the conditional transition seems to be simply ignored...
> Perhaps the following code excerpt from the class org.jbpm.graph.node.Decision is implied :
> Iterator iter = decisionElement.elementIterator("transition");
> while (iter.hasNext()) {
> Element transitionElement = (Element) iter.next();
> Element conditionElement = transitionElement.element("condition");
> if (conditionElement!=null) {
> String conditionExpression = getConditionExpression(conditionElement);
> if (conditionExpression!=null) {
> String transitionName = transitionElement.attributeValue("name");
> if (decisionConditions==null) {
> decisionConditions = new ArrayList();
> }
> decisionConditions.add(new DecisionCondition(transitionName, conditionExpression));
> }
> }
> }
> }
> What occurs if the transition has no name attribute value ?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Closed: (JBPM-1049) ending task does not save form data
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-1049?page=all ]
Tom Baeyens closed JBPM-1049.
-----------------------------
Resolution: Won't Fix
the web console is mainly used for rapid prototyping. so we won't spend effort on making it more complete. also because the console will probably be redone in GWT technology. the simple workaround is not to click the transition links :-)
if people in the community submit a patch for it, they can reopen this case and we gladly incorporated it.
> ending task does not save form data
> -----------------------------------
>
> Key: JBPM-1049
> URL: http://jira.jboss.com/jira/browse/JBPM-1049
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Web Interface
> Affects Versions: jBPM jPDL 3.2.1
> Environment: tomcat 5.0.28, mysql 5.0.37 macbook pro, jbpm-jpdl-3.2.1
> Reporter: Ross McDonald
> Assigned To: Tom Baeyens
>
> Hi,
> when I specify required=true on form inputs for task forms generated with the eclipse plugin, the validation does indeed occur when pressing the save button on the task form in the jbpm-console webapp, and the data is saved correctly in the database. However, it seems that when I end a task with the end transition, the process is completely separate from any save functionality. It would seem that data the user should still be prompted to enter data into required fields, and that this data should be saved.
> Perhaps there is a workaround I am unaware of, or I can attach javascript to trap for this? Any help is appreciated, thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months
[JBoss JIRA] Updated: (JBPM-627) Cancel timer problem
by Tom Baeyens (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-627?page=all ]
Tom Baeyens updated JBPM-627:
-----------------------------
Fix Version/s: jBPM jPDL 3.2.4
> Cancel timer problem
> --------------------
>
> Key: JBPM-627
> URL: http://jira.jboss.com/jira/browse/JBPM-627
> Project: JBoss jBPM
> Issue Type: Bug
> Components: Core Engine
> Affects Versions: jBPM 3.1
> Environment: Windows XP Pro
> Database: DB2/400 v5r3, HSQLDB
> Reporter: Mark Shotton
> Assigned To: Tom Baeyens
> Fix For: jBPM jPDL 3.2.4
>
> Attachments: JBPM-627-screenshots.doc
>
>
> As reported in issue JBPM-594, timers do not get deleted on the cancel-timer event. This is because in SchedulerSession.cancelTimersByName(String, Token), the timer is deleted by a call to SchedulerSession.deleteTimer:
> public void deleteTimer(Timer timer) {
> if (! deletedTimers.contains(timer)) {
> try {
> session.delete(timer);
> deletedTimers.add(timer);
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e);
> }
> }
> }
> but in SchedulerThread, the timer is saved again if timer.getRepeat() is not null:
> public long executeTimers() {
> long millisTillNextTimerIsDue = -1;
> boolean isDueDateInPast = true;
>
> JbpmContext jbpmContext = jbpmConfiguration.createJbpmContext(jbpmContextName);
> try {
> SchedulerSession schedulerSession = jbpmContext.getSchedulerSession();
>
> log.debug("checking for timers");
> Iterator iter = schedulerSession.findTimersByDueDate();
> while( (iter.hasNext())
> && (isDueDateInPast)
> ) {
> Timer timer = (Timer) iter.next();
> log.debug("found timer "+timer);
>
> // if this timer is due
> if (timer.isDue()) {
> log.debug("executing timer '"+timer+"'");
>
> // execute
> timer.execute();
>
> // save the process instance
> jbpmContext.save(timer.getProcessInstance());
>
> // notify the listeners (e.g. the scheduler servlet)
> notifyListeners(timer);
>
> // if there was an exception, just save the timer
> if (timer.getException()!=null) {
> schedulerSession.saveTimer(timer);
>
> // if repeat is specified
> } else if (timer.getRepeat()!=null) {
> // update timer by adding the repeat duration
> Date dueDate = timer.getDueDate();
>
> // suppose that it took the timer runner thread a
> // very long time to execute the timers.
> // then the repeat action dueDate could already have passed.
> while (dueDate.getTime()<=System.currentTimeMillis()) {
> dueDate = businessCalendar
> .add(dueDate,
> new Duration(timer.getRepeat()));
> }
> timer.setDueDate( dueDate );
> // save the updated timer in the database
> log.debug("saving updated timer for repetition '"+timer+"' in '"+(dueDate.getTime()-System.currentTimeMillis())+"' millis");
> schedulerSession.saveTimer(timer);
>
> } else {
> // delete this timer
> log.debug("deleting timer '"+timer+"'");
> schedulerSession.deleteTimer(timer);
> }
> } else { // this is the first timer that is not yet due
> isDueDateInPast = false;
> millisTillNextTimerIsDue = timer.getDueDate().getTime() - System.currentTimeMillis();
> }
> }
>
> } finally {
> jbpmContext.close();
> }
> A work-around was suggested in JBPM-594:
> "As workaround now I do remove timer myself in action just before calling signal():
> if(flag) {
> //need to remove scheduler session as it is not removed during event with
> //cancel-timer element
> SchedulerSession schsession = ctx.getJbpmContext().getSchedulerSession();
> Timer timer=(Timer) schsession.findTimersByName("aaa",ctx.getToken()).get(0);
> log.info("found timer:"+timer.getName());
> timer.setRepeat(null);
> timer.setSuspended(true);
> schsession.saveTimer(timer);
>
> ctx.getToken().signal("tonode1");
> }
> "
> However, this does not seem to be thread-safe as the call to findTimersByName sometimes returns a zero-length array and sometimes an exception if the work-around code to cancel the timer executes before the timer is available from the SchedulerSession (and this does happen even when the code to cancel the timer is within the ActionHandler of the timer) As a different work-around, I set the timer repeat to null in the SchedulerSession.deleteTimer method to ensure that it will not be saved again in the SchedulerThread.executeTimers method:
> public void deleteTimer(Timer timer) {
> if (! deletedTimers.contains(timer)) {
> try {
> session.delete(timer);
> deletedTimers.add(timer);
> //MWS 06/04/06 workaround to ensure that timer is deleted
> timer.setRepeat(null);
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timer+"' from the database", e);
> }
> }
> }
> However, this causes an occasional exception to be thrown:
> org.jbpm.persistence.JbpmPersistenceException: couldn't commit hibernate session
> at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:171)
> at org.jbpm.svc.Services.close(Services.java:211)
> at org.jbpm.JbpmContext.close(JbpmContext.java:138)
> at org.jbpm.scheduler.impl.SchedulerThread.executeTimers(SchedulerThread.java:161)
> at org.jbpm.scheduler.impl.SchedulerThread.run(SchedulerThread.java:70)
> Caused by: org.hibernate.StaleStateException: Unexpected row count: 0 expected: 1
> at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:27)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2204)
> at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2118)
> at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2374)
> at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:84)
> at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:243)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:227)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:353)
> On further investigation, it appears that on some occasions, when deleting a timer on a cancel-timer event, the call to session.getNamedQuery("SchedulerSession.findTimersByName") causes a hibernate flush to occur which attempts to update a timer that has already been deleted:
> public void cancelTimersByName(String timerName, Token token) {
> try {
> Query query = session.getNamedQuery("SchedulerSession.findTimersByName");
> query.setString("timerName", timerName);
> query.setEntity("token", token);
> Iterator iter = query.list().iterator();
> while(iter.hasNext()) {
> deleteTimer((Timer) iter.next());
> }
>
> } catch (Exception e) {
> log.error(e);
> jbpmSession.handleException();
> throw new JbpmException("couldn't delete timer '"+timerName+"' on '"+token+"' from the database", e);
> }
> }
> I have some screenshots below to illustrate this but cannot include them in this form. The attempt to cancel the timer ?processing_error_task_timer? causes the following query to be issued:
> <query name="SchedulerSession.findTimersByName">
> <![CDATA[
> select t
> from org.jbpm.scheduler.exe.Timer t
> where t.name = :timerName
> and t.token = :token
> ]]>
> </query>
> which in turn causes hibernate to flush and attempt to issue the SQL statement:
> update JBPM_TIMER set NAME_=?, DUEDATE_=?, REPEAT_=?, TRANSITIONNAME_=?, EXCEPTION_=?, ISSUSPENDED_=?, ACTION_=?, TOKEN_=?, PROCESSINSTANCE_=?, TASKINSTANCE_=?, GRAPHELEMENTTYPE_=?, GRAPHELEMENT_=? where ID_=?
> where the ID_ of the timer is that of a previous timer that has already been deleted from the database called ?credit_referral_task_timer? (I confirmed this by inspection of the JBPM_TIMER table).
> I am at a loss to explain how the hibernate cache contains a timer that has already been deleted from the database.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 11 months