Hi Isuru,

For the release, can we ask users to run the cluster in a mode where only
one node write to the SVN repo and other nodes will just read?

Also, please explain your fixes to someone/ commit them to the new trunk
once we are done with the release. I think those fixes are the right long
time answer to this problem.

--Srinath


On Mon, Jul 9, 2012 at 5:00 PM, Isuru Suriarachchi <[email protected]> wrote:

>
>
> 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.
>>
>
> Yes, actually I implemented it more than month ago and I still have the
> patches attached to [1]. As I described during the meeting, the issue with
> that approach is handling ESB artifacts. The solution proposed for that was
> to lock the ESB UI if there's a C-App deployed. But in addition to that,
> there can be many edge cases of that approach. As we are at the end of the
> release cycle, after a discussion with Azeez, I just thought of handling it
> in the manner described above. Because it will need only C-App related
> fixes.
>
> Thanks,
> ~Isuru
>
> [1] https://wso2.org/jira/browse/CARBON-13078
>
>
>>
>> Can we solve this problem by doing the above?
>>
>> --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/
>>
>
>
>
> --
> Isuru Suriarachchi
> Senior Technical Lead
> WSO2 Inc. http://wso2.com
> email : [email protected]
> blog : http://isurues.wordpress.com/
>
> lean . enterprise . middleware
>
>


-- 
============================
Srinath Perera, Ph.D.
  Senior Software Architect, WSO2 Inc.
  Visiting Faculty, University of Moratuwa
  Member, Apache Software Foundation
  Research Scientist, Lanka Software Foundation
  Blog: http://srinathsview.blogspot.com/
  Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to