Hi Srinath, On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera <srin...@wso2.com> wrote:
> Hi Isuru, > > In a review we talked about possibility of not deploying artifacts inside > the CApp back to repo, but deploying them by extracting them into a temp > directory and invoking the respective deployers directly, without using the > hot deployment. IMHO, that is the clean way to handle CApp deployments. > > I think we agreed for the above. > > Can we solve this problem by doing the above? > We (Kasun, KasunG and me) had a chat on this and we will try to implement an SynchronusCarAppDeployer service (and Admin service) to handle this. The idea of this service is to deploy all the artefacts before Admin service sends the response. In implementation wise, it will extract the CApp file to a temp location and call each and every deployer manually. Since all deployers are Axis2 Deployers this method should work for all those applications. This method may not work for things like custom mediators, but this way we can address this problem for most of the common cases. thanks, Amila. > --Srinath > > On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi <is...@wso2.com> 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. >> >> 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 : is...@wso2.com >> blog : http://isurues.wordpress.com/ >> >> lean . enterprise . middleware >> >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://www.cs.indiana.edu/~hperera/ > http://srinathsview.blogspot.com/ > > _______________________________________________ > Dev mailing list > Dev@wso2.org > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
