> > things like caching correctly between all of the members of > > Fair enough. So your front-end application takes care of > synchronization, right? Should be a complicated thing. :-)
Well my app currently controlling locking in that users must use its interfaces to lock any resource and its currently the only interface to slide. But that will change as we want to expose it to DAV clients one day. I don't know how slide's locking will behave with clustered caching. There could be timing issues between client's trying to acquire the same lock. > > the cluster. The Slide cluster shares a single content > > filesystem so that files are kept consistent between the > > members. I don't know whether you can take advantage of > > clustered slide servers from the slide api if it isn't a > > remote client api. > > If all Slides share the same storage any application that > uses Side api uses this storage as well. Doesn't solve the > caching problem though. The slide servers may share the content store but the slide api isn't a remote api, and so if the slide server it is talking to fails it can't failover to another server in the cluster. With the WebDAV client it is a remote client and so it can failover to another server in the cluster. Scalability and failover is the big benefit that comes with the DAV client right now. I just wanted to be sure you knew this when making any future decisions for your app. Warwick > -----Original Message----- > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > Sent: Monday, September 13, 2004 8:08 PM > To: 'Slide Users Mailing List' > Subject: RE: Using the slide api directly vs. using the webdav client > > > > -----Original Message----- > > From: Slide Users Mailing List > [mailto:[EMAIL PROTECTED] > > Sent: Monday, September 13, 2004 8:38 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Using the slide api directly vs. using the > webdav client > > Importance: Low > > > > > > > Well, theoretically Tomcat 5 allows clustering: > > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto.Html > > > And a set of tomcats can be load-balanced using various > techniques: > > > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/balancer-howto.html > > > So you don't need to implement all this explicitly - what > you have > > > done in your WebDAV client-based front-end, right? Do I > > still miss something? > > > I'm not an expert in this area, sorry. > > > > My client app doesn't have the load-balancing support, we > > were planning on using a hardware http > > load-balancer/accelerator. We're also using Tomcat 4.1.30 not > > Tomcat 5 right now so we can't use Tomcat clustering. Whether > > a hardware load-balancer is significantly better than > > software load-balancing is arguable but we have used > > load-balancers for all of our apps in the past. > > I see, thanks. > > > Tomcat clustering alone is not enough to cluster Slide > > servers. Tomcat clusters allow you to spread load between > > multiple Tomcat servers but the apps themselves don't > > automatically become "clusterable" simply because the servlet > > engine is. Slide needs to be cluster-enabled too, to handle > > things like caching correctly between all of the members of > > Fair enough. So your front-end application takes care of > synchronization, right? Should be a complicated thing. :-) > > > the cluster. The Slide cluster shares a single content > > filesystem so that files are kept consistent between the > > members. I don't know whether you can take advantage of > > clustered slide servers from the slide api if it isn't a > > remote client api. > > If all Slides share the same storage any application that > uses Side api uses this storage as well. Doesn't solve the > caching problem though. > > > Yours sincerely, > Andrey. > > > > > > James may be able to shed more light on whether the api will > > work with slide api clients and clustered servers within Tomcat. > > > > Warwick > > > > > > > -----Original Message----- > > > From: Andrey Shulinsky [mailto:[EMAIL PROTECTED] > > > Sent: Monday, September 13, 2004 6:33 PM > > > To: 'Slide Users Mailing List' > > > Subject: RE: Using the slide api directly vs. using the > > webdav client > > > > > > > > > > > Can't one use the same scalable/clustered config but > > make requests > > > directly > > > > > - I mean, without this WebDAV client proxy? Please > > correct me, if > > > > > I'm > > > wrong or if I > > > > > have misunderstood you. Or do you suggest running two > > application > > > servers - one for > > > > > the slide only and another for the custom back-end which > > > calls slide > > > > > by > > > means of the > > > > > WebDAV client - so that both can be > > load-balanced/clustered/etc.? > > > > > > > > Right. I'm referring to a configuration that we're > > planning to use > > > > with multiple slide servers that are clustered for failover and > > > > load-balancing with a single (or multiple) slide WebDAV > > client-based > > > > applications front-ending the servers and a HTTP > > load-balancer (or > > > > tomcat load-balancing) in between. In this case if a > single slide > > > > server goes down, or the load is high, then requests can > > be farmed > > > > out to the rest of the slide cluster for maximum uptime and > > > > performance. > > > > The slide servers share the same content repository > between them. > > > > With a slide api app that's coresident with the slide > > server, in the > > > > same web container and making calls directly to slide, > > then I didn't > > > > think it was possible for this client app to failover to another > > > > slide server (in another app server?) in the event of > > failure. That > > > > is, unless the slide api has been written to use remote calls to > > > > find other slide servers on the same machine or another > > machine? Or > > > > does J2EE take care of it somehow?? > > > > > > Well, theoretically Tomcat 5 allows clustering: > > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/cluster-howto. > > html > > And a set of tomcats can be load-balanced using various techniques: > > http://jakarta.apache.org/tomcat/tomcat-5.0-doc/balancer-howto.html > > So you don't need to implement all this explicitly - what you > > have done in your WebDAV client-based front-end, right? Do I > > still miss something? I'm not an expert in this area, sorry. > > > > > > > > I really don't know enough about the possible scenarios for > > deploying > > > the slide api and server so I'll ask some questions about your > > > configuration :-) > > > > I understand. Frankly, our current client doesn't need all > > this clustering/load-balancing stuff - they have just about > > 30 users total. > > However, our solution could be sold to a couple of other > > companies who are considerably bigger so I'm very much > > interested in your work as well. :-) > > > > > What happens if the app server hosting your slide api > > client and slide > > > server goes down? Do you have a failover app server to go > > to in this > > > event? > > > Does each failover app server run its own instance of the > slide api > > > app and slide server? Do the slide servers share the same content > > > repository? > > > > Right now we just have a failover server which content is > > synchronized with the main one's content once per... well... > > I believe, once per day, but I'm not sure. :-) It is supposed > > to be used if the main server crushes. > > > > Yours sincerely, > > Andrey. > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
