[J2EE Design Patterns] - Distributed Task Management
by tkutz_isobar
I am looking for feedback on a pattern we have started using, as we would prefer to have it reviewed before we convert more of our system over to using it.
The scenario we face, is that we have a fairly straight-forward workflow, without any true decision points along the way, only failure paths, and a couple of parallelization points. Because the workflow itself is both simple and static, we haven't seen the need to go for a full blown workflow engine or ESB. The point of the processing that we are concerned with, is the parallelization. At a certain point within processing our overall job, we are able to parallelized, and request several of the same component be launched, each working on a subset of the total dataset to be processed. The workflow must then be notified of each of those jobs completing, which it waits for before moving on to the following step.
The first implementation, used JMS to launch the parallel tasks, and temporary queues in the reply-to for the messages, allowing each job to respond to the originator as they start and finish. However, this has a couple problems:
1 - Temporary queues do not appear to support failover, at least on the JMS implementation we are using (JBoss Messaging 1.4), making this solution intolerant to node failure within the cluster.
2 - Since both parent and child tasks are run through services which throttle the processing, and the parent task is still alive while waiting for the child tasks to run, we are wasting processing slots, while the parent is waiting.
To deal with this, we attempted a new pattern. In this pattern, a job originator launches one StatefulSessionBean for the job, followed by JMS messages into a Queue for each of the child tasks. The child tasks then respond by issuing messages for start, finish and/or failure, into a Topic, with the job id as an attribute which can be used to filter the messages. The SFSB then subscribes to the topic, using a filter to look only at messages for the job it was created for, and polls for messages from the child processes.
The polling is implemented using an EJB3 timer on a stateless session bean, which in turn looks up the SFSB indicated by the object attached to the timer, and calls the polling method. The return value of the polling method determines if a new timer is scheduled or not. In between calls, the SFSB proxy is stored in JNDI, under a well defined context and job-specific name. It is removed when the job has either succeeded, or failed, including a timeout failure, if the jobs did not all complete within a specified window.
So far, this is working well, but we are wondering if there are any pitfalls with the approach, particularly with respect to storing the SFSB handle in JNDI, or the use of a Topic with message filters to manage message routing.
If anyone here has any comments, they'd be greatly appreciated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163620#4163620
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163620
17 years, 10 months
[Installation, Configuration & DEPLOYMENT] - Datasource Lookup Problem
by ruewan
I am trying to deploy an application that has predefined datasource names
I added a jboss-web.xml to the web-inf folder with these contents
<jboss-web>
<resource-ref>
<res-ref-name>jdbc/blah</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<jndi-name>java:blah</jndi-name>
</resource-ref>
</jboss-web>
The web.xml has the following resource ref
<resource-ref>
jdbc/blah Connection
<res-ref-name>blah</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<%
javax.naming.InitialContext ctxt = new javax.naming.InitialContext();
javax.sql.DataSource ds = (javax.sql.DataSource) ctxt.lookup("jdbc/blah");
java.sql.Connection conn = ds.getConnection();
%>
<%=conn%>
<%conn.close();%>
when i run the app i get the following exception
javax.servlet.ServletException: javax.naming.NameNotFoundException: jdbc not bound
if i change the look up from ctxt.lookup("jdbc/blah"); to ctxt.lookup("java:jdbc/blah"); it works.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163619#4163619
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163619
17 years, 10 months
[JBoss jBPM] - Re: does this design make sense?
by twiceknightly
"dOoMi" wrote : -> resources: i'm sorry, i'm new to the discussion board, too. so i have no idea where to find the original discussion thread.
|
| -> exception: the exception is caught after all in org.jbpm.svc.Services in Line 226. The original Exception is caught earlier but gets wrapped into a JbpmPersistenceException and is thrown further.
|
| -> locking-mechanism: you could also use a simple process variable to indicate the locking. as kukeltje stated the problem is the failover-scenario. what happens if the server crashes and the lock stays?
|
| another approach might be to change the isolaotion-level of the database. this way you could take advantage of the existing locking-mechnism provided by your database.
It's good to have you on here dOoMi. Thanks for the info.
I didn't think you could use a process variable to do the locking because the contextInstance, in which the variables is stored, is also a shared object like the processInstance.
What I did think you could do is create a new task in your process instance that you have to claim and have in your personal task list before you can do anything. This is analogous to claiming a lock. Tasks can have timers so if the server crashes then the timer is still in the database and will eventually timeout. When it times out the task owner will be reset to null.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4163616#4163616
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4163616
17 years, 10 months