Hi Isuru, Please find my comments inline.
On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi <[email protected]> wrote: > Hi all, > > I'm trying to fix [1]. Here's the root cause for this issue.. > > Imagine a Carbon cluster with 2 nodes where the svn based deployment > synchronizer (DS) is configured. When a C-App is deployed to node1, it is > extracted and individual artifacts are copied into respective hot > directories. When the DS runs for the first time, it copies the C-App into > node2 and it will be deployed there. When the DS runs again in node1, it > will try to copy the individual artifacts to node2. But node2 already has > those artifacts as the C-App id already deployed in node2. Therefore an svn > conflict occurs. > > To resolve this issue, there are two possible options.. > > 1. Keeping all artifacts coming from C-Apps out of the repository > (repository/deployment/server) > 2. Keeping the original C-App out of the repository > > Initially I tried option 1 above and programetically called the relevant > deployers for individual artifacts. But this creates lot of problems with > some artifacts (Ex: ESB stuff). Therefore, I'm trying to solve the initial > problem using option 2 above. > > I've taken the carbonapps directory out of repository/deployment/server > directory and kept it as repository/carbonapps (we can change this if > needed). Still the carbonapps directory has hot deployment capabilities. > But it won't be synchronized by the DS. So when a C-App is deployed into > node 1, it will be extracted and only the individual artifacts will be > copied into the repository. When the DS runs, all needed artifacts will be > synced to node 2. Therefore, functionality wise, there won't be any issues > on node 2. > I see a possible issue with option2. Currently it is possible to deploy 3rd party dependencies to Carbon Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server extensions such as Custom Mediators, Registry Handlers, filters, etc via C-Apps. When the C-App is deployed in a server, those artifacts gets deployed in to the repository/components/dropins location but not the repository. If we go ahead with option 2 to avoid C-Apps getting picked by DS, how can we handle the syncing of aforementioned Artifact types across a cluster? Thanks and Regards, Harshana > > But if someone logs into the management console of node 2 and go to the > C-App list, nothing will be listed. Is this something we have to fix? > Because anyway in a RW/RO cluster, user can't use the management console of > the slave node. > > WDYT?? > > Thanks, > ~Isuru > > [1] https://wso2.org/jira/browse/CARBON-13598 > > -- > Isuru Suriarachchi > Senior Technical Lead > WSO2 Inc. http://wso2.com > email : [email protected] > blog : http://isurues.wordpress.com/ > > lean . enterprise . middleware > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Harshana Martin Senior Software Engineer WSO2 Inc. : http://wso2.com ; http://wso2.org Mobile: +94 716 062 650 Profile: https://www.google.com/profiles/harshana05 Blog: http://harshana05.blogspot.com Twitter: http://twitter.com/harshana05
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
