On Tue, Nov 6, 2012 at 12:43 PM, Afkham Azeez <[email protected]> wrote:
> > > On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi <[email protected]> wrote: > >> Hi Srinath, >> >> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera <[email protected]> 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. >> > > But how does that work on a cluster? Once you upload an artifact, it is > practically not possible to wait for deployment completion before sending > back a response to the upload request. > There are two modes Synchronous and Asynchronous. 1. There are some users who need to make sure that the .car file is deployed correctly when finish the deployment. For this they can use the this SynchronusCarDeployer where some application like maven plugin has to deploy the .car file to each and every node. No DS involved. 2. In Asynchronous mode the application can deploy the .car file to Manager Node and return immediately. In this case the web service only copy the .car file to relevant folder. After that CApp deployer will extract the artefacts to correct folders and DS synchronise them across the cluster. thanks, Amila. > > >> >> 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 <[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. >>>> >>>> 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 >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://www.cs.indiana.edu/~hperera/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> 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 >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>** > email: **[email protected]* <[email protected]>* cell: +94 77 3320919 > blog: **http://blog.afkham.org* <http://blog.afkham.org>* > twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * > linked-in: **http://lk.linkedin.com/in/afkhamazeez* > * > * > *Lean . Enterprise . Middleware* > > -- *Amila Suriarachchi* Software Architect WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 71 3082805
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
