I think it would be great to have it in the release, does not matter if
it isn't perfect. Just have something that compiles and does something
sensible and we can have it in the release.
Oliver
James Mason wrote:
I'd like to, yes. Most of the work is done, but tonight I'm going to
play with the persistent notification support that Daniel just added. I
think I'll be able to have it done before the 9th.
-James
Oliver Zeigermann wrote:
James, do you intend to have this added to the upcoming 2.1 beta?
Oliver
James Mason wrote:
Warwick Burrows wrote:
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.
That is correct. I'm not so much synchronizing the caches as letting
the Slide instances no when their caches are out of date. It's then
up to each Slide instance to get the most recent data.
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?
Currently any child store that returns true for cacheResults() is
cached by the ExtendedStore. All of the RDBMS stores and the TxFile
stores return true for this method. There are parameters that will
let you disable caching for the different store types (nodestore,
contentstore, securitystore, etc), but unless you set those
parameters caching is enabled for all of them. The cache-mode effect
the behavior of all of the caches.
The "cache notifications" that I am implementing only deals with the
cache that ExtendedStore manages. So in answer to your question, as
long as you're using the JDBCStore or TxFile*Store yes, cache
notifications will happen. It doesn't matter what the Store contains.
I haven't looked at the new Memory store, but since there's no way
that I know of to share memory between multiple servers this store
won't work with clustering.
The JNDIPrincipalStore manages its own cache, so the cache
notifications won't effect it. That cache is self refreshing, though,
so it should already work in a cluster.
-James
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]
---------------------------------------------------------------------
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]
