+1. This clustering configurations let replicate data services and proxy services in AS and ESB slaves in runtime if I use the Deployment Synchronizer?
Thanks, Ing. Jorge Infante Osorio. J´Dpto Soluciones SOA. CDAE. UCI De: [email protected] [mailto:[email protected]] En nombre de Kasun Indrasiri Enviado el: domingo, 29 de mayo de 2011 7:40 Para: [email protected] Asunto: Re: [Carbon-dev] We should have a carbon 3.2.0 clustering configuration and best practice guide +1. We currently have clustering guides for each products and we replicate more or less the same thing in all docs. (However, there can be product specific configuration related to clustering). We recently created a new deployment guide[attached] for ESB which covers most areas related to clustering. On Sun, May 29, 2011 at 4:47 PM, Sameera Jayasoma <[email protected]> wrote: +1 for having a platform-wide clustering guide. Thanks, Sameera On Sun, May 29, 2011 at 4:42 PM, Charitha Kankanamge <[email protected]> wrote: Folks, While configuring and testing product clusters in 3.2.0 release cycle, we came across several issues because of the multiple options we have with clustering setup configurations. At the basic level, we can configure a product cluster with mounted governance and configuration registries. Then, we can have multiple modes of distributed caching mechanisms associated with cluster. eg:- distributed, replicated, invalidation, local We also have Axis2 clustering (tribes) which can be configured through axis2.xml. Deployment synchronizer also plays a important role in a product cluster from 3.2.0 release onwards. Now, with all these options, it will be extremely difficult for a user to figure out the most useful and best clustering configuration. Therefore, we should prepare a document or wiki with all these information. We came across errors such as "org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [10 seconds] on key [org.wso2.carbon.caching.core.registry.RegistryCacheKey@ce8858d] for requestor [Thread[OOB-2,localhost-36388,5,Thread Pools]]! Lock held by [(another thread)]" when starting replicated caching enabled cluster nodes in parallel. As discussed with Senaka, we should start all nodes sequentially in such a cluster setup. We also came across several issues when running a cluster if the caching mode is set to "distributed". So, the recommended approach should be "replicated" mode. We also noticed that the cluster becomes inconsistent if the P2 features are not installed correctly in each node in a cluster. Most importantly, it is difficult (or impossible) to figure out the root cause if an error occurs in an inconsistent cluster setup. We should let users know which configurations are replicated among cluster nodes and which are not. For example, carbon datasources, message stores, processors etc.. are not replicated among child nodes of a cluster. We should prepare a clustering best practices and guideline doc and ship or host in OT with 3.2.0 release. Associated JIRA:- https://wso2.org/jira/browse/CARBON-10487 Regards Charitha _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Sameera Jayasoma Technical Lead and Product Manager, WSO2 Carbon WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://tech.jayasoma.org Lean . Enterprise . Middleware _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev -- Kasun Indrasiri Senior Software Engineer WSO2, Inc.; http://wso2.com lean.enterprise.middleware cell: +94 71 536 4128 Blog : http://kasunpanorama.blogspot.com/ _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
