Hi Rafael, I believe it should be, when you use MySQL or PostgreSQL as the database. Avoid H2 (the default DB) since each DB instance would not be shared across EAP instances. I'll verify whether the proposed config works flawlessly over the weekend, as I am working on demonstrating scaling of TicketMonster using a Kubernetes+WildFly+(MySQL/Postgres)+HAProxy. Vineet ----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt;, jbossdeveloper(a)lists.jboss.org > Sent: Friday, February 27, 2015 8:16:29 PM > Subject: Ticket Monster session replication > > Hi all, > > I'm preparing a presentation demo using Ticket Monster and I'd like to > demonstrate a failover cluster. > > Is TM capable of session replication ? I mean: Did someone already > tested if enabling it through <distributable /> element would be > sufficient for TM without any other source code modification ? > > -- > > *Rafael Benevides | Senior Software Engineer* > JBoss Developer > M: +1-919-592-6255 > > Red Hat > > Better technology. Faster innovation. Powered by community collaboration. > See how it works at www.redhat.com <http://www.redhat.com/> > > LinkedIn <http://www.linkedin.com/company/3258288> Youtube > <https://www.youtube.com/redhatlatam> >

----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt; > Cc: jbossdeveloper(a)lists.jboss.org > Sent: Friday, February 27, 2015 9:26:59 PM > Subject: Re: Ticket Monster session replication > > " I am working on demonstrating scaling of TicketMonster using a > Kubernetes+WildFly+(MySQL/Postgres)+HAProxy" > > Me too :) > > Let's chat about this when you have a chance. Anytime will do. Let's use IRC or Google Hangouts. For the record, I've gotten a sample clustering app to work on a WildFly cluster running on Kubernetes, using the help of this article: http://mluksa.blogspot.in/2015/01/deploying-wildfly-cluster-on-openshift_... I dont intend to use OpenShift yet, because of one outstanding issue involving Kubernetes - autoregistering changes in the cluster with an upstream loadbalancer. You wouldn't run into this issue with OpenShift and other cloud platforms like GCE that use Kubernetes, since the load balancers on such platforms would be informed of changes to the cluster. But with Kubernetes alone, this becomes an issue, since you need to hand rig code to add or remove IP routes to Docker instances from the upstream load balancer. There are a few ways to solve this: * For a very small and static cluster configuration, manually register the IP addresses of the cluster with HAProxy or nginx. This approach obviously doesn't scale since it is manual for the most part. * Automate the registration and discovery process for the load balancer. To do this, use etcd (the distributed key-value store in k8s) to store changes to the infrastructure. Read them in the upstream load balancer; assuming nginx, you can use nginx in conjunction with confd. As an example, refer: http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero... * Or look at something more sophisticated like vulcand. vulcand is not considered production-ready by most people. But that looks to be the future. As an example refer: http://www.recorditblog.com/post/how-to-create-a-web-scale-infrastructure... I'm evaluating points 2 and 3 wrt TicketMonster. I may eventually look at Ceph (as an object storage platform) in the context of vulcand, but that is not a priority for me at the moment. > On 2/27/15 10:54, Vineet Reynolds Pereira wrote: >> Hi Rafael, >> >> I believe it should be, when you use MySQL or PostgreSQL as the >> database. Avoid H2 (the default DB) since each DB instance would not >> be shared across EAP instances. I'll verify whether the proposed >> config works flawlessly over the weekend, as I am working on >> demonstrating scaling of TicketMonster using a >> Kubernetes+WildFly+(MySQL/Postgres)+HAProxy. >> >> Vineet >> >> >> ----- Original Message ----- >>> From: "Rafael Benevides" <benevides(a)redhat.com&gt; >>> To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt;, >>> jbossdeveloper(a)lists.jboss.org >>> Sent: Friday, February 27, 2015 8:16:29 PM >>> Subject: Ticket Monster session replication >>> >>> Hi all, >>> >>> I'm preparing a presentation demo using Ticket Monster and I'd like to >>> demonstrate a failover cluster. >>> >>> Is TM capable of session replication ? I mean: Did someone already >>> tested if enabling it through <distributable /> element would be >>> sufficient for TM without any other source code modification ? >>> >>> -- >>> >>> *Rafael Benevides | Senior Software Engineer* >>> JBoss Developer >>> M: +1-919-592-6255 >>> >>> Red Hat >>> >>> Better technology. Faster innovation. Powered by community collaboration. >>> See how it works at www.redhat.com <http://www.redhat.com/> >>> >>> LinkedIn <http://www.linkedin.com/company/3258288> Youtube >>> <https://www.youtube.com/redhatlatam> >>> >

----- Original Message ----- > From: "Rafael Benevides" <benevides(a)redhat.com&gt; > To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt; > Cc: jbossdeveloper(a)lists.jboss.org > Sent: Tuesday, March 3, 2015 1:44:39 AM > Subject: Re: Ticket Monster session replication > > Cool, > > At this moment I'm preparing the docker images to them update it to be > orchestrated through Kubernetes. > > I'm using 4 images for the demo: > > - DB: Postgres > - Webserver: Apache + modcluster > - Widlfy domain > - n wildfly servers > > I'm facing some issues with the DB internal ip change (when db container > is restarted) but I believe that Kubernetes services can solve this. A DNS based service discovery helps here. Check out SkyDock (https://github.com/crosbymichael/skydock) and Consul (https://www.consul.io/). There is also an ambassador pattern for this use case, but it does not solve the problem if you link the client to the ambassador; it is there just to prevent restarting the client when the client to the service (db in this case) goes down. The pattern is documented @ https://docs.docker.com/articles/ambassador_pattern_linking/ > I'll keep you informed > > On 3/2/15 05:04, Vineet Reynolds Pereira wrote: >> ----- Original Message ----- >>> From: "Rafael Benevides" <benevides(a)redhat.com&gt; >>> To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt; >>> Cc: jbossdeveloper(a)lists.jboss.org >>> Sent: Friday, February 27, 2015 9:26:59 PM >>> Subject: Re: Ticket Monster session replication >>> >>> " I am working on demonstrating scaling of TicketMonster using a >>> Kubernetes+WildFly+(MySQL/Postgres)+HAProxy" >>> >>> Me too :) >>> >>> Let's chat about this when you have a chance. >> Anytime will do. Let's use IRC or Google Hangouts. >> >> For the record, I've gotten a sample clustering app to work on a WildFly >> cluster running on Kubernetes, using the help of this article: >> http://mluksa.blogspot.in/2015/01/deploying-wildfly-cluster-on-openshift_... >> >> I dont intend to use OpenShift yet, because of one outstanding issue >> involving Kubernetes - autoregistering changes in the cluster with an >> upstream loadbalancer. You wouldn't run into this issue with OpenShift and >> other cloud platforms like GCE that use Kubernetes, since the load >> balancers on such platforms would be informed of changes to the cluster. >> But with Kubernetes alone, this becomes an issue, since you need to hand >> rig code to add or remove IP routes to Docker instances from the upstream >> load balancer. >> >> There are a few ways to solve this: >> >> * For a very small and static cluster configuration, manually register the >> IP addresses of the cluster with HAProxy or nginx. This approach obviously >> doesn't scale since it is manual for the most part. >> * Automate the registration and discovery process for the load balancer. To >> do this, use etcd (the distributed key-value store in k8s) to store >> changes to the infrastructure. Read them in the upstream load balancer; >> assuming nginx, you can use nginx in conjunction with confd. As an >> example, refer: >> http://brianketelsen.com/2014/02/25/using-nginx-confd-and-docker-for-zero... >> * Or look at something more sophisticated like vulcand. vulcand is not >> considered production-ready by most people. But that looks to be the >> future. As an example refer: >> http://www.recorditblog.com/post/how-to-create-a-web-scale-infrastructure... >> >> I'm evaluating points 2 and 3 wrt TicketMonster. I may eventually look at >> Ceph (as an object storage platform) in the context of vulcand, but that >> is not a priority for me at the moment. >> >>> On 2/27/15 10:54, Vineet Reynolds Pereira wrote: >>>> Hi Rafael, >>>> >>>> I believe it should be, when you use MySQL or PostgreSQL as the >>>> database. Avoid H2 (the default DB) since each DB instance would not >>>> be shared across EAP instances. I'll verify whether the proposed >>>> config works flawlessly over the weekend, as I am working on >>>> demonstrating scaling of TicketMonster using a >>>> Kubernetes+WildFly+(MySQL/Postgres)+HAProxy. >>>> >>>> Vineet >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Rafael Benevides" <benevides(a)redhat.com&gt; >>>>> To: "Vineet Reynolds Pereira" <vpereira(a)redhat.com&gt;, >>>>> jbossdeveloper(a)lists.jboss.org >>>>> Sent: Friday, February 27, 2015 8:16:29 PM >>>>> Subject: Ticket Monster session replication >>>>> >>>>> Hi all, >>>>> >>>>> I'm preparing a presentation demo using Ticket Monster and I'd like to >>>>> demonstrate a failover cluster. >>>>> >>>>> Is TM capable of session replication ? I mean: Did someone already >>>>> tested if enabling it through <distributable /> element would be >>>>> sufficient for TM without any other source code modification ? >>>>> >>>>> -- >>>>> >>>>> *Rafael Benevides | Senior Software Engineer* >>>>> JBoss Developer >>>>> M: +1-919-592-6255 >>>>> >>>>> Red Hat >>>>> >>>>> Better technology. Faster innovation. Powered by community >>>>> collaboration. >>>>> See how it works at www.redhat.com <http://www.redhat.com/> >>>>> >>>>> LinkedIn <http://www.linkedin.com/company/3258288> Youtube >>>>> <https://www.youtube.com/redhatlatam> >>>>> >