[JBoss JIRA] Resolved: (BPEL-196) jbpm and bpel services do not play together well
by Alejandro Guizar (JIRA)
[ http://jira.jboss.com/jira/browse/BPEL-196?page=all ]
Alejandro Guizar resolved BPEL-196.
-----------------------------------
Resolution: Done
Applied the configuration changes contained in the patch to the head branch. Beta 2 will include the jBPM identity component and add it to the BPEL service archive for compatibility with jPDL processes. End users will still be responsible for building and deploying the jBPM web console separately.
Writing a section in the user guide describing how to build and deploy the jBPM web console will be tracked in a separate issue.
> jbpm and bpel services do not play together well
> ------------------------------------------------
>
> Key: BPEL-196
> URL: http://jira.jboss.com/jira/browse/BPEL-196
> Project: JBoss jBPM BPEL
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Engine
> Affects Versions: jBPM BPEL 1.1 beta 1
> Reporter: Alejandro Guizar
> Assigned To: Alejandro Guizar
> Priority: Critical
> Fix For: jBPM BPEL 1.1 beta 2
>
> Attachments: jbpm-bpel-1.1-beta1-bpel-196.zip, jbpmBpel.properties, jbpmBpel.script
>
>
> When deploying a jPDL process or even accessing the jbpm web application, the following exception arises:
> java.lang.NullPointerException
> at org.jbpm.JbpmContext.setActorId(JbpmContext.java:453)
> at org.jbpm.web.JbpmContextFilter.doFilter(JbpmContextFilter.java:81)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:81)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
> at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke(CustomPrincipalValve.java:39)
> at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
> at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
> at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
> at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
> at java.lang.Thread.run(Thread.java:595)
--
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
19 years, 11 months
[JBoss JIRA] Created: (JBMESSAGING-449) Persisted messages not removed on acknowledgement
by Lakshmi Dasari (JIRA)
Persisted messages not removed on acknowledgement
-------------------------------------------------
Key: JBMESSAGING-449
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-449
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core Persistence
Affects Versions: 1.0.1.CR2
Environment: Jboss4.0.3SP1 and Jboss messaging 1.0.1CR2
Jboss4.0.4GA and Jboss messaging 1.0.1 CR2
Reporter: Lakshmi Dasari
Assigned To: Ovidiu Feodorov
I have configured Oracle persistence with Jboss messaging and I have created the tables required for persistence in Oracle database. It appears to me that the messages are redelivered even after the messages are successfully received and processed by the consumer.
While I am sending a message, I am marking the message as persistent and creating a non-transacted session with Session.AUTO_ACKNOWLEDGE.
On server startup, my MessageListeners are picking up the messages again from the queue.
My configuration:
Jboss 4.0.3SP1
Jboss message 1.0.1 CR2
Oracle 10G
--
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
19 years, 11 months
[JBoss JIRA] Commented: (JBPM-627) Cancel timer problem
by Derek Chen-Becker (JIRA)
[ http://jira.jboss.com/jira/browse/JBPM-627?page=comments#action_12340281 ]
Derek Chen-Becker commented on JBPM-627:
----------------------------------------
I've been trying to step through this and I've found something interesting with the SchedulerSession. On my system, the scheduler session appears to be using a PersistenceContext for its hibernate session with flushMode set to AUTO. I'm wondering if setting the repeat to null is causing it to update automatically. If so, then something is wrong with the session.delete() that gets called, because the timer is not actually being detached from the session. I've gone through the code manually several times and I can't find any place where the timer would be saved or updated, so while this may be a shot in the dark, it's the only thing I've been able to come up with so far.
> 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
> 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
19 years, 11 months
[JBoss JIRA] Updated: (JBMESSAGING-428) Stress tests fail
by Tim Fox (JIRA)
[ http://jira.jboss.com/jira/browse/JBMESSAGING-428?page=all ]
Tim Fox updated JBMESSAGING-428:
--------------------------------
Fix Version/s: 1.0.1.GA
(was: 1.0.1.CR4)
> Stress tests fail
> -----------------
>
> Key: JBMESSAGING-428
> URL: http://jira.jboss.com/jira/browse/JBMESSAGING-428
> Project: JBoss Messaging
> Issue Type: Bug
> Reporter: Ovidiu Feodorov
> Assigned To: Ovidiu Feodorov
> Fix For: 1.0.1.GA
>
>
> [junit] main 18:46:45,187 INFO [StressTest] ####################################################### Start IN-VM test: testTopicMultipleReceivers
> [junit] main 18:46:45,187 INFO [ServerManagement] IN-VM TEST
> [junit] main 18:46:45,250 INFO [WrapperDataSourceService] Bound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' to JNDI name 'java:/DefaultDS'
> [junit] main 18:46:45,281 INFO [ServiceContainer] remoting = "socket", serialization = "jboss", database = "mysql"
> [junit] main 18:46:45,593 INFO [ServerPeer] JBoss Messaging 1.0.1.CR3 server [server.0] started
> [junit] main 18:46:45,593 INFO [ConnectionFactory] Connector has leasing enabled, lease period 20000 milliseconds
> [junit] main 18:46:45,593 INFO [ConnectionFactory] [/ConnectionFactory, /XAConnectionFactory, java:/ConnectionFactory, java:/XAConnectionFactory] deployed
> [junit] main 18:46:45,609 INFO [ConnectionFactoryBindingService] Bound ConnectionManager 'jboss.jca:name=JCAConnectionFactory,service=ConnectionFactoryBinding' to JNDI name 'java:/JCAConnectionFactory'
> [junit] main 18:46:45,609 INFO [LocalTestServer] server started
> [junit] main 18:46:45,609 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,640 INFO [Queue] Queue[/queue/Queue1] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,640 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,671 INFO [Queue] Queue[/queue/Queue2] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,671 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,687 INFO [Queue] Queue[/queue/Queue3] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,687 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,703 INFO [Queue] Queue[/queue/Queue4] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,703 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,718 INFO [Topic] Topic[/topic/Topic1] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,718 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,734 INFO [Topic] Topic[/topic/Topic2] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,734 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,750 INFO [Topic] Topic[/topic/Topic3] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] main 18:46:45,750 INFO [LocalTestServer] deploying queue, fullsize:3000, ps:1000 dc size:1000
> [junit] main 18:46:45,765 INFO [Topic] Topic[/topic/Topic4] started, fullSize=3000, pageSize=1000, downCacheSize=1000
> [junit] Thread-90 18:49:42,609 ERROR [TransactionalReceiver] Message is null
> [junit] Thread-82 18:49:47,765 ERROR [Receiver] Message is null
> [junit] Thread-86 18:50:02,140 ERROR [RecoveringReceiver] Message is null
> [junit] Thread-96 18:50:09,000 ERROR [Transactional2PCReceiver] Message is null
> [junit] Thread-94 18:50:32,015 ERROR [Transactional2PCReceiver] Message is null (rollback)
> [junit] Thread-88 18:50:33,937 ERROR [RecoveringReceiver] Message is null
> [junit] Thread-92 18:50:37,828 ERROR [TransactionalReceiver] Message is null
> [junit] main 18:50:37,828 INFO [Queue] Queue[/queue/Queue1] stopped
> [junit] main 18:50:37,828 INFO [Queue] Queue[/queue/Queue2] stopped
> [junit] main 18:50:37,828 INFO [Queue] Queue[/queue/Queue3] stopped
> [junit] main 18:50:37,828 INFO [Queue] Queue[/queue/Queue4] stopped
> [junit] main 18:50:37,828 INFO [Topic] Topic[/topic/Topic1] stopped
> [junit] main 18:50:37,828 INFO [Topic] Topic[/topic/Topic2] stopped
> [junit] main 18:50:37,828 INFO [Topic] Topic[/topic/Topic3] stopped
> [junit] main 18:50:37,828 INFO [Topic] Topic[/topic/Topic4] stopped
> [junit] main 18:50:37,828 INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:name=JCAConnectionFactory,service=ConnectionFactoryBinding' from JNDI name 'java:/JCAConnectionFactory'
> [junit] main 18:50:37,828 INFO [ConnectionFactory] [/ConnectionFactory, /XAConnectionFactory, java:/ConnectionFactory, java:/XAConnectionFactory] undeployed
> [junit] main 18:50:37,843 INFO [ServerPeer] JMS ServerPeer [server.0] stopped
> [junit] main 18:50:37,843 INFO [ConnectionFactoryBindingService] Unbound ConnectionManager 'jboss.jca:name=DefaultDS,service=DataSourceBinding' from JNDI name 'java:/DefaultDS'
> [junit] main 18:50:37,843 INFO [LocalTestServer] server stopped
> [junit] main 18:50:37,843 INFO [StressTest] ####################################################### Stop IN-VM test: testTopicMultipleReceivers
> No exception in logs.
--
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
19 years, 11 months