This is exactly what I needed James. Thanks! > They should be asynchronous. Daniel Florey wrote the > notification mechanism, so he can confirm, but I'm pretty > sure on this.
Daniel, can you confirm that notifications are asynchronous? Or is there a write-up on the notifications that I can look at? And I have another question on the cluster cache :-) There is a "base-uri" parameter that is specified in the configuration. If this is set to "/files" will it pick up all changes to objects under /files? For example when a file is checked out/in with a new revision will it also notify other slide servers of /history path updates that stem from the change even though /history isn't specifically configured as the base-uri? Thanks, Warwick > -----Original Message----- > From: James Mason [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 07, 2004 8:40 PM > To: Warwick Burrows; Slide Users Mailing List > Subject: Re: Cluster cache > > > On Tue, 2004-12-07 at 18:10 -0800, Warwick Burrows wrote: > > Hi James, > > > > I was hoping you could answer some questions about the > cluster cache > > design. We would like to go into production with Slide but doing so > > requires the cluster cache implementation -- or no caching at all > > which is not even an option :-) We need to know the cluster cache > > mechanics so we can cater for them. > > > > - Are the updates (notifications) between servers performed > > synchronously or asynchronously? > > They should be asynchronous. Daniel Florey wrote the > notification mechanism, so he can confirm, but I'm pretty > sure on this. When a resource is modified the server sends > notifications to all subscribers that there are events > waiting for them. The subscribers (other servers) then POLL > the server and get a list of changed resources. Each > subscriber then removes the resource in the list from their cache. > > > - If an update to a server fails will it be retried? > > It depends on where the failure is. If a subscriber is unable > to POLL a server, it will retry. In fact, each subscriber > periodically POLLs the server just to be sure it hasn't > missed any notifications. The POLL frequency should be configurable. > > > > > Any other design points I should be aware of? > > Not that I can think of. > > > > > Incidentally I had mentioned that locks could be an issue with the > > cache design in that two lock requests coming in at the > same time may > > both return with the lock. It isn't an issue for us though > as locking > > is controlled by our DAV applications and the lock information they > > share is stored in a DB. Only one app is guaranteed to get the lock > > and so create a Slide lock. One way to mitigate this > problem for other > > clients may be to allow for the "lockstore" store to be > specifically > > configured so that only lock related metadata isn't cached. > > ExtendedStore has five (I think) separate caches. You can set > the size of each cache by setting parameters on the store. > One of the caches is for locks. Take a look at the source for > ExtendedStore, since I'm not sure where, if anywhere, the > parameters are documented. > > -James > > > > > Thanks, > > Warwick > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
