[Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

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

Re: [Dev] C-App synchronization in a Carbon cluster

[Harshana Martin]

Hi Isuru,

Please find my comments inline.

On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi  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.
>

I see a possible issue with option2.

Currently it is possible to deploy 3rd party dependencies to Carbon Servers
using JavaLibraryArtifact C-App Artifact type and Carbon Server extensions
such as Custom Mediators, Registry Handlers, filters, etc via C-Apps. When
the C-App is deployed in a server, those artifacts gets deployed in to the
repository/components/dropins location but not the repository.

If we go ahead with option 2 to avoid C-Apps getting picked by DS, how can
we handle the syncing of aforementioned Artifact types across a cluster?

Thanks and Regards,
Harshana

>
> 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
>
>


-- 
Harshana Martin
Senior Software Engineer
WSO2 Inc. : http://wso2.com ; http://wso2.org
Mobile: +94 716 062 650
Profile: https://www.google.com/profiles/harshana05
Blog: http://harshana05.blogspot.com
Twitter: http://twitter.com/harshana05
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Afkham Azeez]

On Sat, Jul 7, 2012 at 2:39 AM, Harshana Martin  wrote:

> Hi Isuru,
>
> Please find my comments inline.
>
> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi  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.
>>
>
> I see a possible issue with option2.
>
> Currently it is possible to deploy 3rd party dependencies to Carbon
> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server
> extensions such as Custom Mediators, Registry Handlers, filters, etc via
> C-Apps. When the C-App is deployed in a server, those artifacts gets
> deployed in to the repository/components/dropins location but not the
> repository.
>
>
Deploying artifacts into dropins is a major issue! It does not work for
tenants, so is broken anyway. Anything that does not work in multi-tenant
mode in terms of deployment, can safely be considered to be broken.


> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how can
> we handle the syncing of aforementioned Artifact types across a cluster?
>
> Thanks and Regards,
> Harshana
>
>>
>> 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
>>
>>
>
>
> --
> Harshana Martin
> Senior Software Engineer
> WSO2 Inc. : http://wso2.com ; http://wso2.org
> Mobile: +94 716 062 650
> Profile: https://www.google.com/profiles/harshana05
> Blog: http://harshana05.blogspot.com
> Twitter: http://twitter.com/harshana05
>
>
>
> ___
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

Harshana, good point.. Actually I had forgot about the lib artifacts.
Anyway as Azeez mentioned, we only allow lib artifacts for super tenant. So
it's kind of broken already.

If we want the libs to work with option 2, we can simply add a new deployer
for libs as well.. :)

Thanks,
~Isuru

On Sat, Jul 7, 2012 at 5:55 AM, Afkham Azeez  wrote:

>
>
> On Sat, Jul 7, 2012 at 2:39 AM, Harshana Martin  wrote:
>
>> Hi Isuru,
>>
>> Please find my comments inline.
>>
>> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi 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.
>>>
>>
>> I see a possible issue with option2.
>>
>> Currently it is possible to deploy 3rd party dependencies to Carbon
>> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server
>> extensions such as Custom Mediators, Registry Handlers, filters, etc via
>> C-Apps. When the C-App is deployed in a server, those artifacts gets
>> deployed in to the repository/components/dropins location but not the
>> repository.
>>
>>
> Deploying artifacts into dropins is a major issue! It does not work for
> tenants, so is broken anyway. Anything that does not work in multi-tenant
> mode in terms of deployment, can safely be considered to be broken.
>
>
>> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how
>> can we handle the syncing of aforementioned Artifact types across a
>> cluster?
>>
>> Thanks and Regards,
>> Harshana
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Harshana Martin
>> Senior Software Engineer
>> WSO2 Inc. : http://wso2.com ; http://wso2.org
>> Mobile: +94 716 062 650
>> Profile: https://www.google.com/profiles/harshana05
>> Blog: http://harshana05.blogspot.com
>> Twitter: http://twitter.com/harshana05
>>
>>
>>
>> ___
>> 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/
> * **
> email: **az...@wso2.com* * cell: +94 77 3320919
> blog: **http://blog.afkham.org* *
> twitter: **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

Re: [Dev] C-App synchronization in a Carbon cluster

[Kasun Gajasinghe]

Hi Isuru,

I'd like to add a third option to the list for consideration. :)

How about doing the synchronization between cluster nodes AFTER the C-App's
extracted artifacts are deployed? I'm not sure whether it's possible to do
with the current architecture, but if it is, then I think things will be
easier.
But with this option, there could be issues in node 2. That's because node
2 will also try to deploy the C-App as well in addition to its artifacts!
Hope that can be fixed!

WDYT?

Thanks,
--KasunG

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.
>>>
>>
>> I see a possible issue with option2.
>>
>> Currently it is possible to deploy 3rd party dependencies to Carbon
>> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server
>> extensions such as Custom Mediators, Registry Handlers, filters, etc via
>> C-Apps. When the C-App is deployed in a server, those artifacts gets
>> deployed in to the repository/components/dropins location but not the
>> repository.
>>
>>
> Deploying artifacts into dropins is a major issue! It does not work for
> tenants, so is broken anyway. Anything that does not work in multi-tenant
> mode in terms of deployment, can safely be considered to be broken.
>
>
>> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how
>> can we handle the syncing of aforementioned Artifact types across a
>> cluster?
>>
>> Thanks and Regards,
>> Harshana
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Harshana Martin
>> Senior Software Engineer
>> WSO2 Inc. : http://wso2.com ; http://wso2.org
>> Mobile: +94 716 062 650
>> Profile: https://www.google.com/profiles/harshana05
>> Blog: http://harshana05.blogspot.com
>> Twitter: http://twitter.com/harshana05
>>
>>
>>
>> ___
>> 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/
> * **
> email: **az...@wso2.com* * cell: +94 77 3320919
> blog: **http://blog.afkham.org* *
> twitter: **http://twitter.com/afkham_azeez*
> *
> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
> *
> *
> *Lean . Enterprise . Middleware*
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Kasun Gajasinghe*
Software Engineer;
Development Technologies Team, WSO2 Inc.; http://wso2.com ,
*email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
*linked-in: *http://lk.linkedin.com/in/gajasinghe*
*
*blog: **http://blog.kasunbg.org* *
twitter: **http://twitter.com/kasunbg* *
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Muhammed Shariq]

On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi  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.
>

Also we will lose the relationship between the C-App and its artifacts
right? For example, now if we delete the C-App, then all its dependent
artifacts will get undeployed automatically etc. But as per 2nd solution,
in node 2 the dependent artifacts will be independent resources, so if we
want to undeploy the C-App, we should manually remove the
dependent artifacts from the respective lists. Of course functionality wise
there shouldn't be any issues ...

>
> 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
>
>


-- 
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Mon, Jul 9, 2012 at 10:55 AM, Muhammed Shariq  wrote:

>
> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi  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.
>>
>
> Also we will lose the relationship between the C-App and its artifacts
> right? For example, now if we delete the C-App, then all its dependent
> artifacts will get undeployed automatically etc. But as per 2nd solution,
> in node 2 the dependent artifacts will be independent resources, so if we
> want to undeploy the C-App, we should manually remove the
> dependent artifacts from the respective lists.
>

No that won't be the case, the relationship between the C-App and it's
artifacts will be there on node 1. So when the C-App is deleted on node 1,
all respective arficats will be deleted. When the DS runs, it will make
sure all those will be deleted at node 2 as well. You can't use the
management console of node 2 in any case.

Thanks,
~Isuru


> Of course functionality wise there shouldn't be any issues ...
>
>>
>> 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
>>
>>
>
>
> --
> Thanks,
> Shariq.
> Phone: +94 777 202 225
>
>


-- 
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

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Sat, Jul 7, 2012 at 11:01 AM, Kasun Gajasinghe  wrote:

> Hi Isuru,
>
> I'd like to add a third option to the list for consideration. :)
>
> How about doing the synchronization between cluster nodes AFTER the
> C-App's extracted artifacts are deployed?
>

This is kind of not possible with the current implementation. That is
because, C-App doesn't know when the individual artifacts will get
deployed. It just copies the artifacts into hot directories.

And also the synchronization will be called for each and every deployment
cycle, it doesn't know whether there's a C-App to be deployed..

Thanks,
~Isuru


> I'm not sure whether it's possible to do with the current architecture,
> but if it is, then I think things will be easier.
> But with this option, there could be issues in node 2. That's because node
> 2 will also try to deploy the C-App as well in addition to its artifacts!
> Hope that can be fixed!
>
> WDYT?
>
> Thanks,
> --KasunG
>
> 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.

>>>
>>> I see a possible issue with option2.
>>>
>>> Currently it is possible to deploy 3rd party dependencies to Carbon
>>> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server
>>> extensions such as Custom Mediators, Registry Handlers, filters, etc via
>>> C-Apps. When the C-App is deployed in a server, those artifacts gets
>>> deployed in to the repository/components/dropins location but not the
>>> repository.
>>>
>>>
>> Deploying artifacts into dropins is a major issue! It does not work for
>> tenants, so is broken anyway. Anything that does not work in multi-tenant
>> mode in terms of deployment, can safely be considered to be broken.
>>
>>
>>> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how
>>> can we handle the syncing of aforementioned Artifact types across a
>>> cluster?
>>>
>>> Thanks and Regards,
>>> Harshana
>>>

 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


>>>
>>>
>>> --
>>> Harshana Martin
>>> Senior Software Engineer
>>> WSO2 Inc. : http://wso2.com ; http://wso2.org
>>> Mobile: +94 716 062 650
>>> Profile: https://www.google.com/profiles/harshana05
>>> Blog: http://harshana05.blogspot.com
>>> Twitter: http://twitter.com/harshana05
>>>
>>>
>>>
>>> ___
>>> 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/
>> * **
>> email: **az...@wso2.com* * cell: +94 77 3320919
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Kasun Gajasinghe*
> Software Engineer;
> Development Technologies Team, WSO2 Inc.; http://wso2.com ,
> *email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
> *linked-in: *http://lk.linkedin.com/in/gajasinghe*
> *
>  *blog: **http://blog.kasunbg.org* 

Re: [Dev] C-App synchronization in a Carbon cluster

[Harshana Martin]

Hi Isuru,

On Sat, Jul 7, 2012 at 9:48 AM, Isuru Suriarachchi  wrote:

> Harshana, good point.. Actually I had forgot about the lib artifacts.
> Anyway as Azeez mentioned, we only allow lib artifacts for super tenant. So
> it's kind of broken already.
>
> If we want the libs to work with option 2, we can simply add a new
> deployer for libs as well.. :)
>

+1 for a deployer for Libs because currently if there are artifacts which
uses 3rd party Libraries and users have a cluster deployment, suggested
method to sync the artifacts and the 3rd party jars is to use Lib Artifacts.

So it's kind of integral part of the deployments right now. :)

Thanks and Regards,
Harshana

>
> Thanks,
> ~Isuru
>
>
> On Sat, Jul 7, 2012 at 5:55 AM, Afkham Azeez  wrote:
>
>>
>>
>> On Sat, Jul 7, 2012 at 2:39 AM, Harshana Martin wrote:
>>
>>> Hi Isuru,
>>>
>>> Please find my comments inline.
>>>
>>> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi 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.

>>>
>>> I see a possible issue with option2.
>>>
>>> Currently it is possible to deploy 3rd party dependencies to Carbon
>>> Servers using JavaLibraryArtifact C-App Artifact type and Carbon Server
>>> extensions such as Custom Mediators, Registry Handlers, filters, etc via
>>> C-Apps. When the C-App is deployed in a server, those artifacts gets
>>> deployed in to the repository/components/dropins location but not the
>>> repository.
>>>
>>>
>> Deploying artifacts into dropins is a major issue! It does not work for
>> tenants, so is broken anyway. Anything that does not work in multi-tenant
>> mode in terms of deployment, can safely be considered to be broken.
>>
>>
>>> If we go ahead with option 2 to avoid C-Apps getting picked by DS, how
>>> can we handle the syncing of aforementioned Artifact types across a
>>> cluster?
>>>
>>> Thanks and Regards,
>>> Harshana
>>>

 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


>>>
>>>
>>> --
>>> Harshana Martin
>>> Senior Software Engineer
>>> WSO2 Inc. : http://wso2.com ; http://wso2.org
>>> Mobile: +94 716 062 650
>>> Profile: https://www.google.com/profiles/harshana05
>>> Blog: http://harshana05.blogspot.com
>>> Twitter: http://twitter.com/harshana05
>>>
>>>
>>>
>>> ___
>>> 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/
>> * **
>> email: **az...@wso2.com* * cell: +94 77 3320919
>> blog: **http://blog.afkham.

Re: [Dev] C-App synchronization in a Carbon cluster

[Muhammed Shariq]

On Mon, Jul 9, 2012 at 12:20 PM, Isuru Suriarachchi  wrote:

>
>
> On Mon, Jul 9, 2012 at 10:55 AM, Muhammed Shariq  wrote:
>
>>
>> On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi 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.
>>>
>>
>> Also we will lose the relationship between the C-App and its artifacts
>> right? For example, now if we delete the C-App, then all its dependent
>> artifacts will get undeployed automatically etc. But as per 2nd solution,
>> in node 2 the dependent artifacts will be independent resources, so if we
>> want to undeploy the C-App, we should manually remove the
>> dependent artifacts from the respective lists.
>>
>
> No that won't be the case, the relationship between the C-App and it's
> artifacts will be there on node 1. So when the C-App is deleted on node 1,
> all respective arficats will be deleted. When the DS runs, it will make
> sure all those will be deleted at node 2 as well. You can't use the
> management console of node 2 in any case.
>

Yup, if we don't use the UI in node2 no issues would arise ...

>
> Thanks,
> ~Isuru
>
>
>> Of course functionality wise there shouldn't be any issues ...
>>
>>>
>>> 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
>>>
>>>
>>
>>
>> --
>> Thanks,
>> Shariq.
>> Phone: +94 777 202 225
>>
>>
>
>
> --
> Isuru Suriarachchi
> Senior Technical Lead
> WSO2 Inc. http://wso2.com
> email : is...@wso2.com
> blog : http://isurues.wordpress.com/
>
> lean . enterprise . middleware
>
>


-- 
Thanks,
Shariq.
Phone: +94 777 202 225
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Srinath Perera]

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?

--Srinath

On Fri, Jul 6, 2012 at 6:05 PM, Isuru Suriarachchi  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
>
>


-- 

Srinath Perera, Ph.D.
   http://www.cs.indiana.edu/~hperera/
   http://srinathsview.blogspot.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Srinath Perera]

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  wrote:

>
>
> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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 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
>>>
>>>
>>
>>
>> --
>> 
>> 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 : is...@wso2.com
> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Mon, Jul 9, 2012 at 5:07 PM, Srinath Perera  wrote:

> 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?
>

I think we always recommend only one R/W node in a cluster.


>
> Also, please explain your fixes to someone/ commit them to the new trunk
> once we are done with the release.
>

Sure, will do..


> I think those fixes are the right long time answer to this problem.
>

+1

Thanks,
~Isuru


>
> --Srinath
>
>
> On Mon, Jul 9, 2012 at 5:00 PM, Isuru Suriarachchi  wrote:
>
>>
>>
>> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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 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


>>>
>>>
>>> --
>>> 
>>> 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 : is...@wso2.com
>> 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
>



-- 
Isur

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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  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
>>
>>
>
>
> --
> 
> 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 : 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

Re: [Dev] C-App synchronization in a Carbon cluster

[Charitha Kankanamge]

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  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
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

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..

Thanks,
~Isuru

On Wed, Jul 25, 2012 at 10:31 PM, Charitha Kankanamge 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  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

Re: [Dev] C-App synchronization in a Carbon cluster

[Afkham Azeez]

On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi  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?


>
> Thanks,
> ~Isuru
>
>
> On Wed, Jul 25, 2012 at 10:31 PM, Charitha Kankanamge 
> 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 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:

>
>
> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 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 
>> 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 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/
> * **
> email: **az...@wso2.com* * cell: +94 77 3320919
> blog: **http://blog.afkham.org* *
> twitter: **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

Re: [Dev] C-App synchronization in a Carbon cluster

[Samisa Abeysinghe]

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  wrote:

>
>
> On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 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 >> > 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 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/
>> * **
>> email: **az...@wso2.com* * cell: +94 77 3320919
>> blog: **http://blog.afkham.org* *
>> twitter: **http://twitter.com/afkham_azeez*
>> *
>> linked-in: **http://lk.linkedin.com/in/afkhamazeez*
>> *
>> *
>> *Lean . Enterprise . Middleware*
>>
>>
>
>

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Sat, Jul 28, 2012 at 4:06 AM, Samisa Abeysinghe  wrote:

> 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 a separate thread, I've already asked Kicha to test this including all
possible scenarios..

Thanks,
~Isuru


>
>
> On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi wrote:
>
>>
>>
>> On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 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 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; A

Re: [Dev] C-App synchronization in a Carbon cluster

[Harshana Martin]

Hi Isuru,

I believe this new C-App deploymement location can be derived using tenant?

Otherwise the Dev Studio C-App deployment feature will be broken.

Thanks and Regards,
Harshana
On Jul 28, 2012 8:14 PM, "Isuru Suriarachchi"  wrote:

>
>
> On Sat, Jul 28, 2012 at 4:06 AM, Samisa Abeysinghe wrote:
>
>> 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 a separate thread, I've already asked Kicha to test this including all
> possible scenarios..
>
> Thanks,
> ~Isuru
>
>
>>
>>
>> On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi wrote:
>>
>>>
>>>
>>> On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:
>>>


 On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 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 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 Suriar

Re: [Dev] C-App synchronization in a Carbon cluster

[Isuru Suriarachchi]

On Sat, Jul 28, 2012 at 8:33 PM, Harshana Martin  wrote:

> Hi Isuru,
>
> I believe this new C-App deploymement location can be derived using tenant?
>
Yes.. It's CARBON_HOME/tmp/tenants//carbonapps/

Thanks,
~Isuru

> Otherwise the Dev Studio C-App deployment feature will be broken.
>
> Thanks and Regards,
> Harshana
> On Jul 28, 2012 8:14 PM, "Isuru Suriarachchi"  wrote:
>
>>
>>
>> On Sat, Jul 28, 2012 at 4:06 AM, Samisa Abeysinghe wrote:
>>
>>> 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 a separate thread, I've already asked Kicha to test this including all
>> possible scenarios..
>>
>> Thanks,
>> ~Isuru
>>
>>
>>>
>>>
>>> On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi wrote:
>>>


 On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:

>
>
> On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 
> 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 
>>> 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

Re: [Dev] C-App synchronization in a Carbon cluster

[Kishanthan Thangarajah]

On Sat, Jul 28, 2012 at 6:43 PM, Isuru Suriarachchi  wrote:

>
>
> On Sat, Jul 28, 2012 at 4:06 AM, Samisa Abeysinghe wrote:
>
>> 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 a separate thread, I've already asked Kicha to test this including all
> possible scenarios..
>

Yes, i'm in the process of testing those scenarios.

>
> Thanks,
> ~Isuru
>
>
>>
>>
>> On Fri, Jul 27, 2012 at 10:55 AM, Isuru Suriarachchi wrote:
>>
>>>
>>>
>>> On Thu, Jul 26, 2012 at 2:55 PM, Afkham Azeez  wrote:
>>>


 On Thu, Jul 26, 2012 at 12:17 AM, Isuru Suriarachchi 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 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://isurue

Re: [Dev] C-App synchronization in a Carbon cluster

[Amila Suriarachchi]

Hi Srinath,

On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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.

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  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
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://www.cs.indiana.edu/~hperera/
>http://srinathsview.blogspot.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Amila Suriarachchi]

hi Srinath,

On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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.

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  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
>>
>>
>
>
> --
> 
> Srinath Perera, Ph.D.
>http://www.cs.indiana.edu/~hperera/
>http://srinathsview.blogspot.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> 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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Kasun Gajasinghe]

The relevant JIRA  - https://wso2.org/jira/browse/CARBON-13078

On Mon, Nov 5, 2012 at 6:51 PM, Amila Suriarachchi  wrote:

> hi Srinath,
>
> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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.
>
> 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 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
>>>
>>>
>>
>>
>> --
>> 
>> Srinath Perera, Ph.D.
>>http://www.cs.indiana.edu/~hperera/
>>http://srinathsview.blogspot.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> 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
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
*Kasun Gajasinghe*
Software Engineer;
Development Technologies Team, WSO2 Inc.; http://wso2.com ,
*email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
*linked-in: *http://lk.linkedin.com/in/gajasinghe*
*
*blog: **http://blog.kasunbg.org* *
twitter: **http://twitter.com/kasunbg* *
*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Afkham Azeez]

On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi  wrote:

> Hi Srinath,
>
> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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.


>
> 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 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
>>>
>>>
>>
>>
>> --
>> 
>> Srinath Perera, Ph.D.
>>http://www.cs.indiana.edu/~hperera/
>>http://srinathsview.blogspot.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> 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
> 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/
* **
email: **az...@wso2.com* * cell: +94 77 3320919
blog: **http://blog.afkham.org* *
twitter: **http://twitter.com/afkham_azeez*
*
linked-in: **http://lk.linkedin.com/in/afkhamazeez*
*
*
*Lean . Enterprise . Middleware*
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] C-App synchronization in a Carbon cluster

[Amila Suriarachchi]

On Tue, Nov 6, 2012 at 12:43 PM, Afkham Azeez  wrote:

>
>
> On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi  wrote:
>
>> Hi Srinath,
>>
>> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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 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


>>>
>>>
>>> --
>>> 
>>> Srinath Perera, Ph.D.
>>>http://www.cs.indiana.edu/~hperera/
>>>http://srinathsview.blogspot.com/
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Am

Re: [Dev] C-App synchronization in a Carbon cluster

[Amila Suriarachchi]

On Tue, Nov 6, 2012 at 12:43 PM, Afkham Azeez  wrote:

>
>
> On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi  wrote:
>
>> Hi Srinath,
>>
>> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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 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


>>>
>>>
>>> --
>>> 
>>> Srinath Perera, Ph.D.
>>>http://www.cs.indiana.edu/~hperera/
>>>http://srinathsview.blogspot.com/
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Am

Re: [Dev] C-App synchronization in a Carbon cluster

[Srinath Perera]

Do we need a review?

--Srinath

On Tue, Nov 6, 2012 at 1:22 PM, Amila Suriarachchi  wrote:

>
>
> On Tue, Nov 6, 2012 at 12:43 PM, Afkham Azeez  wrote:
>
>>
>>
>> On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi wrote:
>>
>>> Hi Srinath,
>>>
>>> On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera  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 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
>
>


 --
 
 Srinath Perera, Ph.

Re: [Dev] C-App synchronization in a Carbon cluster

[Amila Suriarachchi]

On Thu, Nov 8, 2012 at 9:13 AM, Srinath Perera  wrote:

> Do we need a review?


+1

thanks,
Amila.


>
> --Srinath
>
> On Tue, Nov 6, 2012 at 1:22 PM, Amila Suriarachchi  wrote:
>
>>
>>
>> On Tue, Nov 6, 2012 at 12:43 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Mon, Nov 5, 2012 at 6:48 PM, Amila Suriarachchi wrote:
>>>
 Hi Srinath,

 On Mon, Jul 9, 2012 at 3:21 PM, Srinath Perera 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 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
>>>