Hi Tammo, Thank you for your feedback. I understood your feedback and considered it when I prepare my proposal. I have shared the google doc of that proposal here and also I have submitted it to the google melange since I am near to the deadline. It would be helpful if I get some feedback on it, so that I can still edit the proposal and submit it.
Thank you. GSoC 2014 : Clustering for Apache ODE<https://docs.google.com/document/d/1NyQ2B8OXpkZDNGM9nC34r296IJPjnKsQdKa-kRhg1nM/edit?usp=drive_web> On Fri, Mar 21, 2014 at 12:04 AM, Tammo van Lessen <[email protected]>wrote: > Hi Thamayanthy, > > thanks for your interest in this project. I have a couple of comments: > > To 1) Exactly, well observed. This would also include some kind of leader > election and re-election in case the master disappears. > To 2) ODE's scheduler is already node-aware. The only missing piece would > be to tell the scheduler which node it is and to fire heartbeats from other > node, so that the scheduler knows if it needs to reassign jobs from stale > nodes. Hazelcast has IMO a listener interface that helps with that (not > sending heart beats but notifying when nodes come and go). > To 3) This functionality is already there. All process instances are > isolated using XA transactions and locked, so if 1) and 2) are solved, we > should be set. > > Thanks, > Tammo > > > On Thu, Mar 20, 2014 at 4:32 PM, Thamayanthy Sripalan > <[email protected]>wrote: > > > Hi all, > > > > I am Thamayanthy Sripalan, an third year undergraduate of University of > > Moratuwa. > > > > > > I am interested in doing this[1] project as my GSoC project as I am keen > > interested in learning about clustering and I have enough basic > > understanding of the apache axis2, apache ODE, WS-BPEL and BPEL4WS. As I > > guess there are only three features to be implemented in order to cluster > > the ODE engine, those are: > > > > 1. Having and managing a common database/process store for all the nodes > > > > > > - > > > > If only one database is shared among all the nodes the same process > > definition should be shared among all the nodes. If we allow all the > > databased to deploy the processes, due to versioning problem the > running > > instances might get null pointer exception. This will happen because > if > > the > > same process is deployed again, the previous process will go to > retired > > state and the newly deployed one will become the active process. So > the > > previously created process instances will not be able to find their > > process > > definition because the deployed process name will be changed when the > > new > > version of the process is deployed. > > > > > > - > > > > As a solution for this we need to allow only one node(Master node) to > > deploy the processes and other nodes will only read/refer the deployed > > process. > > > > > > 2. Handling assignments of jobs among the nodes > > > > > > - > > > > If one node is running an instance the other node cannot access that > > instance because if two threads/process instances are trying to access > > the > > same job entry in the database there will be a consistency problem. > > > > > > - > > > > To solve this we can have another database table having the > instance_id > > and the node which can handle/execute that job to manage the assigned > > jobs > > of each nodes. If the job assigned node fails then there should be a > > mechanism to distribute that node's jobs to the other alive nodes. > For > > that we can use Hazelcast (I guess) to handle those things. > > > > > > 3. Handling multi threaded environment > > > > > > - > > > > In case if one process instance has more than one services to be > invoked > > in a sequential manner those services can be executed in different > > nodes. > > So that we need to allow multiple nodes to access the same process > > instance's entry in the database. In this case we cannot restrict that > > only > > one node can execute/perform the job. > > > > > > - > > > > To handle this one we can use distributed log to execute a job. so > that > > only one thread can have the access to a particular job entry. I think > > that > > this logging mechanism is already implemented in the single node ODE > > also. > > We need to make sure that the distributed log mechanism is functioning > > when > > we do clustering. > > > > > > Also I have commented this in the jira about the features. > > > > I believe that it is feasible to be implemented within the given time > > frame. > > > > and I would be glad if I am selected to do this project as a GSoC this > > year. > > > > > > Can I take the above mentioned features as my project tasks to be > achieved? > > > > links: > > [1] https://issues.apache.org/jira/browse/ODE-563 > > > > Thank you > > -- > > Thamayanthy Sripalan > > Undergraduate > > Department of Computer Science and Engineering > > University of Moratuwa. > > > > > > -- > Tammo van Lessen - http://www.taval.de > -- Thamayanthy Sripalan Undergraduate Department of Computer Science and Engineering University of Moratuwa.
