Do we need a review?

--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/
_______________________________________________
Dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/dev

Reply via email to