Going back to your configuration you have.. 1) All workpaths on local disk 2) The locks and content (rootpath) are on a shared drive (NFS or similar?) 3) The nodes are in a DB. Is the sequenceStorem securityStore and the revisiondescriptor(s)store in a DB too?
Are there issues with having the locks on a shared drive? I know this is not recommended for mod_dav. On 11/19/05, Warwick Burrows <[EMAIL PROTECTED]> wrote: > > > Hey Tony, > > Yes the work dir I was referring to is set using the workpath variable > which is needed for the transactional file stores. Eg. the stanard tx > file store and the XML file descriptor file store. > > Warwick > -----Original Message----- > > From: Tony [mailto:[EMAIL PROTECTED] > > Sent: Friday, November 18, 2005 12:27 PM > > To: Slide Users Mailing List > > Subject: Re: clustering questions > > > > > > On 11/18/05, Warwick Burrows <[EMAIL PROTECTED]> wrote: > > > > > > > > > Answers below: > > > > > > > -----Original Message----- > > > > From: Tony Tomcat [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, November 17, 2005 7:50 PM > > > > To: [email protected] > > > > Subject: clustering questions > > > > > > > > > > > > I'm in the process of researching the best way to build a WebDAV > > > > system for a large user base. Because the storage is > > still up in the > > > > air and file versioning is desired Slide seems like a > > natural fit. I > > > > know very little about Slide or WebDAV but I'm familiar > > with Tomcat > > > > and HTTP. > > > > > > > > Because I am building a system for a large user base I would need > > > > several tomcat instances and it sounds like the 2.1 clustering > > > > support is what I need but from previous J2EE experience > > I know that > > > > clustering usually involves pinning a user to a specific > > instance of > > > > Tomcat. Is this required in Slide? > > > > > > If you're not using external transactions then I don't > > think you will > > > need to pin your user to a particular tomcat. External transactions > > > are managed using the Slide WebDAV client currently via the > > > startTransaction(), commitTransaction() and abortTransaction() > > > methods. They are a means for you to manage synchronization in your > > > between changes you make in Slide and those you make in your own > > > separate app storage. External transactions require "sticky > > sessions" > > > because once a tx is started on a machine you can't continue or > > > complete it on another server because the tx context is > > stored within > > > the running app and there is no means to transfer this knowledge to > > > another cluster member. > > > > > > Now as for Slide server sessions... I don't know as I have > > a different > > > configuration where the session on the Slide server is not > > significant > > > to authenticating/authorizing the user etc. But even if you > > do want to > > > maintain the session then both Jboss and Tomcat 5 have their own > > > clustering implementation that allows you to share user sessions > > > amongst clustered servers. > > > > > > > > > > In the ideal world users hitting my system would all come > > though a > > > > switch at my.domain.com <http://my.domain.com> <http://my.domain.com> > > < > > > http://my.domain.com>. > > > > Incoming requests would then be > > > > routed randomly to the various tomcat servers in my system. 2 > > > > subsequent requests from the same user would likely hit different > > > > tomcat servers. Does Slide Clustering support this? > > > > > > Yes. From my experience it does. Even when I have external > > > transactions enabled it would work part of the time. It > > wasn't until I > > > put significant load on the system (and it tried to load balance > > > during an external transaction) did I see problems. > > > > > > > Also. Can my locks and content be on different storage systems? I > > > > suspect for clustering to work well I would have user > > files on NFS > > > > (or similar) and the locks would be in a shared database. > > or maybe > > > > I'm just crazy. ;-) > > > > > > You will need to share your content and lock stores between all > > > servers in some way. Your tx file system "work" dirs should not be > > > shared as that's where temporary transaction information is > > stored. We > > > use a tx file store and DB2 node store and we were keeping > > our locks > > > in the DB to share them between servers. But due to the load on the > > > lock table (which creates both normal and transaction locks) the DB > > > was performing badly (-911 errors). > > > > > > ok.. dumb question.. What is the work dir? Is that what is > > specified in the workpath? I've been looking for an > > explaination of the workpath on the slide site and wiki with > > no luck.. Once I get my hands around this I'll try to help > > out with the documentation. ;-) > > > > > > > > So we kept the DB as our node store but reconfigured the > > lockstore to be > > > a tx XML descriptor store. I also found that it was safer > > to configure > > > the "work" dirs for the tx file stores so that they are not shared. > > > This is because slide will rollback any uncompleted txs > > when it starts > > > so if one machine in the cluster goes down and comes back > > it may try > > > to rollback any currently running txs from other cluster > > members that > > > it finds in the shared work dirs. > > > > > > > > > > Thanks in advance for any information! > > > > Tony > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
