Hi Milinda, I believe below are some tasks that we need to do:
1. clustering deployment, or as you said process store synchronization. I am wondering how did you do this, did you create a repository for its deployment registration? 2. heart beat mechanism for detecting cluster node. 3. implement the cluster aware cron scheduler, we can try to extract the cron scheduler API, and then try out the Quartz by leverage its clustering feature. For these three tasks, we will come up an API for them, so that can be plugged into different implementation. I am not sure about the axis2 integration already supports *clustering* in the email that wrote by Alex Boisvert. I thought in the front end, we would expect users to use the httpd to do the load balancing. Let me know what you thought, and what I am missing here. Regards Jeff On Wed, Apr 7, 2010 at 2:25 PM, Milinda Pathirage < [email protected]> wrote: > Hi Jeff, > > I did some initial work on clustering for WSO2 BPS based on clustering > support provided by Axis2. I only implement the process store > synchronization part. But we are planning to start work on clustering > support end of this April. I am happy to help you on this. There are some > nice design documents on OpenESB BPEL clustering at [1]. This may > also helpful when designing the ODE clustering. > > Thanks > Milinda > > [1] http://wiki.open-esb.java.net/Wiki.jsp?page=BPELSEClusteringDesign > > On Wed, Apr 7, 2010 at 8:10 AM, Jeff Yu <[email protected]> wrote: > > > Hi all, > > > > I'd like to bring this topic up, > > https://issues.apache.org/jira/browse/ODE-563, I am going to work on > this > > task, before I do this, I'd like to have a heads up at here. > > > > Below is discussion that I found in the mail archive by Alex Boisvert, > > which > > I think it is very good summary in this area. > > > > " > > The Axis2 integration already supports *clustering*. (Well, maybe a > better > > characterization is that it doesn't get in the way) > > > > There's a few things do to to support *clustering*. First thing would be > > to > > > > make the scheduler *cluster*-aware, to support work distribution (load > > balancing) across different nodes and to avoid contention. I suggested > > using Terracotta as a basis for this, but there may be other (and better) > > ways. > > > > If we want to get more performance out of the system, we can introduce > > varying levels of node affinity to reduce data shipping and improve cache > > efficiency within the *cluster*. This would probably entail some form of > > distributed lock manager, or a registry to redirect messages to process > > instances already loaded on *cluster* nodes. This is an area where > > integration with the messaging layer (Axis2) can help since you can > > establish "sessions" between clients and services to improve message > > routing > > > > and, again, cache efficiency. > > > > The persistence DAOs (OpenJPA and Hibernate) also support > > *clustering*today. > > Both can be configured to be *cluster*-aware and both support the more > > aggressive transparent *cluster* cache such as Terracotta, JBoss Cache, > > etc. > > > > > > Hope this helps, > > alex > > " > > > > From above summary, I believe we have following sub-tasks for the > > clustering. > > > > 1. make cronScheduler cluster-aware. > > 2. simpleScheduler module's DAO need to be implemented as JPA based, so > > that > > it can support cluster. > > 3. make simple scheduler cluster-aware? > > > > Anything I am missing or mis-understanding here?? > > > > -- > > Cheers, > > Jeff Yu > > > > ---------------- > > blog: http://jeff.familyyu.net > > > > > > -- > Milinda Pathirage > Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps > WSO2 <http://wso2.org/bps%0AWSO2> Inc.; http://wso2.com > E-mail: [email protected], [email protected] > Web: http://mpathirage.com > Blog: http://blog.mpathirage.com > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
