I didn't think that this was the case but I wanted to be certain. I think that Daniel has a different idea of what you are doing. Clustered Slide servers and the notifications you're adding can't be separated. You are improving upon the original clustering solution by synchronizing the caches but we will still need to cluster our Slide servers and have them share the same file repository.
So how will this affect metadata stores? Does the "cluster" cache mode set on the <store> element also enable caching of metadata? Ie. I've defined a DB2 metadata store for all store types but the contentstore. So will notifications be sent to other servers when cached metadata needs updating? Thanks, Warwick ----------------------------------------------------------- Warwick Burrows E2open Senior Engineer 9600 Great Hills Trail, #325 http://www.e2open.com Austin TX 78759 ----------------------------------------------------------- -----Original Message----- From: James Mason [mailto:[EMAIL PROTECTED] Sent: Thursday, August 05, 2004 10:54 AM To: Slide Users Mailing List Subject: Re: Cache refresh notification in two different instance of S lide running on different boxes. Warwick Burrows wrote: > Yes, the configuration that you're talking about would be ideal as it > would be a true load-balanced/failover solution since the filesystem > store is no longer a single point of failure as it is with the Slide > cluster solution. > > But James, will what you're doing with cache notifications allow us to > setup multiple Slide servers without cache clustering enabled so that > a write to one server will be propagated to the disk, and not just the > cache, of the other servers? Ie. will the cache notifications that you > send contain the actual updated content from the server that received > the update so that the other servers can write it to disk too; No. > or does the notification just let > the other servers know that they need to flush their version of an > object from the cache and reread it from disk the next time it is > accessed? Yes. I'm afraid writing an ACID-compliant, distributed, WebDAV-enabled filesystem is a bit beyond what I can do at the moment ;). If you know of any work that I could take advantage of in this area, please let me know, but as far as I know none of the opensource databases even support this well. For the time being all your Slide instances will need to point at the same Store. If you can find a way to make the Store distributed, such as with a replicated database, then you won't have a single point of failure. There are several distributed filesystems that you may want to check out as well, depending on what platform you're running on. -James > > Thanks, > Warwick > > > ----------------------------------------------------------- > Warwick Burrows E2open > Senior Engineer 9600 Great Hills Trail, #325 > http://www.e2open.com Austin TX 78759 > ----------------------------------------------------------- > > > -----Original Message----- > From: Daniel Varghese [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 05, 2004 2:17 AM > To: Slide Users Mailing List > Subject: Re: RE: Cache refresh notification in two different instance of > Slide running on different boxes. > > > Hello Burrows, > > I asked this specific question because we have a production > deployment not clustered but, all server instances are deployed on > different boxes and managed thru a H/W loadbalancer. Right now we are > routing all Slide server request to a particular server instance. I > was investigating how we can synchronize the cache information b/w > multiple servers which is running on different machines. > > I really appreciate James and his teams effort to do the cache > synchronization implemenation in Jakarta Slide2.1. > > So we really waiting for August 10 to release the Slide2.1. > > rgds > Daniel > > > On Wed, 4 Aug 2004 12:18:07 -0700 , Warwick Burrows > <[EMAIL PROTECTED]> wrote: > >>Daniel, >> >>I'm a little confused by this question. Why wouldn't you use Slide >>clustering but still synchronize the caches of the two servers? Are >>there features of Slide clusters that you don't want? >> >>James, >> >>What is the Slide clustering design? I remember a note where you said >>that load-balancing is not a function of Slide clustering but that >>cache consistency between servers is. So what other features make up >>Slide's clustering implementation? And what is the underlying network >>transport for the cache update notification events that are sent >>between the servers? >> >>Warwick >> >> >>----------------------------------------------------------- >>Warwick Burrows E2open >>Senior Engineer 9600 Great Hills Trail, #325 >>http://www.e2open.com Austin TX 78759 >>----------------------------------------------------------- >> >> >> >> >>-----Original Message----- >>From: James Mason [mailto:[EMAIL PROTECTED] >>Sent: Wednesday, August 04, 2004 10:50 AM >>To: Slide Users Mailing List >>Subject: Re: Cache refresh notification in two different instance of >>Slide running on different boxes. >> >>Daniel Varghese wrote: >> >>>Hello James, >>> >>>thnx for your valuable information abt Slide Clustering and Cache >>>refresh notifications among the cluster nodes couple of days back. >> >>You're welcome. >> >> >>>Now I have another question. >>> >>>Two instance of Slide running on two different Unix boxes and I'm >>>not planing to use Cluster, In this senario how do we notify the >>>cache information between different server instances. >> >>You don't yet. Hopefully I'll be able to submit the code that does >>this tonight. I upgraded my desktop yesterday evening and there's a >>bug in the mysql update I got, so I haven't been able to test it yet. >> >>-James >> >> >>>Cluster Configuration is a must for cache refresh notification ? >>> >>>rgds >>>Daniel >>> >>>-------------------------------------------------------------------- >>>- >>>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] > > --------------------------------------------------------------------- > 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]
