+1 for Rafal's proposal. We must make ODE clustering possible for both integration layers. When implementing process store synchronization I had to use central repository to store BPEL packages. For that I did my own implementation of Process store and process configuration, we must take these things into consideration when designing clustering API.
Thanks Milinda On Wed, Apr 7, 2010 at 2:27 PM, Rafal Rusin <[email protected]> wrote: > I played with clustering ODE a bit. I think the problem with > clustering is that it doesn't have common public API implemented by > various vendors. > Instead of that, each vendor has it's own clustering extensions. For > example, Axis2 uses Tomcat's tribes. > So I think we need to support various cluster implementations in ODE > in future. This will include SMX3 & 4 too. > So let's make an interface, which will include cluster related > operations, like noticing new node or rewriting http destination while > making outgoing http calls from ODE. This could have pluggable > implementations for various clustering vendors. > > On 7 April 2010 04:40, 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 > > > > > Regards, > -- > Rafał Rusin > http://rrusin.blogspot.com > http://www.touk.pl > http://top.touk.pl > -- Milinda Pathirage Senior Software Engineer & Product Manager WSO2 BPS; http://wso2.org/bps WSO2 Inc.; http://wso2.com E-mail: [email protected], [email protected] Web: http://mpathirage.com Blog: http://blog.mpathirage.com
