Hi Borut, Have you looked at the Tomcat documentation? The last two elements are clustering and load-balancing.
If you using Tomcat or Resin - I would probably recommend putting Apache HTTPD in front of them where you have 2 Tomcat per Apache HTTPD instance. This is a popular setup for uPortal and appears to better utilize the resources on a machine. And if you need to spread load-further, then you will need some type of load-balancer like an F5 or Netscaler. Mark On 8/30/05, Borut Bolčina <[EMAIL PROTECTED]> wrote: > Hello Mark, > > On 29.8.2005 18:23, Mark Wilcox wrote: > > >Hi, > >Tapestry in Action covers managing state. Start with 2.2.4 "Examinging > >the Visit Object" and re-read that section. I think chapter 7 or so > >may also have more information. > > > > > I must have been blind. Years ago I was involved in WebObjects > application development - so the concepts are familiar (Visit alias > Session). > > >But Tapestry in Action will only cover how to maintain state in > >Tapestry - it does not cover clustering directly because that's > >outside the realm of the book. > > > > > Do you know of any real world clustering solution (Resin, Tomcat)? I > will read their docs. > > >Once you are properly maintaining state in a single application server > >instance - then you can explore clustering. Each application server > >will have its capabilities and configuration setup steps. > > > >Also you may need additional hardware such as an F5 load-balancer. > > > >And as Richard Hensley pointed out - you need to determine whether you > >want to do this for scalability or reliability. > > > > > Scalability is the main issue. I guess reliability is more in good > programming practice domain - backed by some hardware setup only helps > of course. > > >mark > > > > > >On 8/29/05, Borut Bolčina <[EMAIL PROTECTED]> wrote: > > > > > >>Hi, a little late. Getting to our administrator was a time consuming task. > >> > >>Now, he says we are using LVS (Linux Virtual Server) to balance requests > >>(all sessionless). I guess the same would be true for sessionless > >>Tapestry web app. What if sessions become requirement for the new web app? > >> > >>An article about deploying Tapestry app in multiserver environment would > >>be great. I read Howard's article > >>http://www.theserverside.com/articles/article.tss?l=TSSTapestry, but it > >>focuses on translating JSPs to Tapestry. > >> > >>I have a book "Tapestry in Action", but it doesn't cover this topic. Did > >>I miss it? Anyway, links to material appreciated! > >> > >>Regards, > >>Borut > >> > >>On 26.8.2005 17:53, Hensley, Richard wrote: > >> > >> > >> > >>>Borut, > >>> > >>>Do the current JSP application run in a clustered environment? There should > >>>be very little difference between your JSP application deployment and a > >>>Tapestry application deployment across a cluster. > >>>Can you be a little more specific about the issues you are encountering or > >>>anticipate? > >>> > >>>Richard > >>> > >>>-----Original Message----- > >>>From: Borut Bolcina [mailto:[EMAIL PROTECTED] > >>>Sent: Friday, August 26, 2005 1:05 AM > >>>To: [email protected] > >>>Subject: Load balancing > >>> > >>>Hello, > >>> > >>>can someone point me to a resource where I can learn how to deploy > >>>tapestry application on several linux machines to handle [per day]: > >>> > >>> * 150.000 unique visitors > >>> * 1.500.000 pages > >>> > >>>This holds true for our current JSP app, so the pages number might not > >>>be informative. > >>> > >>>Is such high volume traffic site at all possible with Tapestry? > >>> > >>>Regards, > >>>Borut Bolčina > >>> > >>> > >>> > >>>--------------------------------------------------------------------- > >>>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> > >>--------------------------------------------------------------------- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
