Charitha - good catch! Isuru, thanks for the quick fix!!
AS folks, can we please do a preliminary verification of the fix done by Isuru, before it hits the formal QA cycle? On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi <is...@wso2.com> wrote: > > > On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez <az...@wso2.com> wrote: > >> >> >> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi <is...@wso2.com>wrote: >> >>> Oh.. I was planning to create different directories for different >>> tenants inside repository/carbonapps. But looks like I've missed that. I'll >>> fix it and let you know.. >> >> >> Tenants have their own temp directory right? If so, why can't we use >> those directories to store these? >> > > Yes, that's better than having another set of tenant spaces under > repository/carbonapps. So I fixed it that way and tested with ST and > tenants. I'm going to commit it now. > > Charitha, please test it with GD on/off as well on next pack. > > Thanks, > ~Isuru > > >> >> >>> >>> Thanks, >>> ~Isuru >>> >>> >>> On Wed, Jul 25, 2012 at 10:31 PM, Charitha Kankanamge <chari...@wso2.com >>> > wrote: >>> >>>> Hi, >>>> >>>> It seems we have not thought about MT aspects of this model. Now, the >>>> carbonapps directory is taken out from repository/deployment/server and the >>>> all CApps will be stored in common carbonapps directory regardless of the >>>> tenant who deployed CApp. Because of this, any tenant can see others CApps >>>> :( I came across this [1] issue in latest AS probably because of this >>>> change. >>>> >>>> >>>> [1]https://wso2.org/jira/browse/CARBON-13691 >>>> >>>> >>>> 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 >>>>> >>>>> >>>> >>> >>> >>> -- >>> 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 >>> >>> >> >> >> -- >> *Afkham Azeez* >> Director of Architecture; WSO2, Inc.; http://wso2.com >> Member; Apache Software Foundation; http://www.apache.org/ >> * <http://www.apache.org/>** >> email: **az...@wso2.com* <az...@wso2.com>* 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* >> >> > > > -- > 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 > > Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
