You can have a look at the package.html in the event package (javadocs). Also have a look at google: notification webdav (ms exchange site). I've implemented the notifications in the same way that it is done in Ms Exchange (with some extensions regarding the depth-header). Cheers, Daniel
> -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Im Auftrag von Warwick Burrows > Gesendet: Mittwoch, 8. Dezember 2004 19:24 > An: 'Slide Users Mailing List' > Betreff: RE: Cluster cache > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
