On Thu, Nov 8, 2012 at 9:13 AM, Srinath Perera <[email protected]> wrote:
> Do we need a review? +1 thanks, Amila. > > --Srinath > > On Tue, Nov 6, 2012 at 1:22 PM, Amila Suriarachchi <[email protected]> wrote: > >> >> >> 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 >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > http://www.cs.indiana.edu/~hperera/ > http://srinathsview.blogspot.com/ > -- *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
