I'm planning on it being in 2.1. I updated my system last night and
there's a bug in MySQL in the latest debian unstable, so I'm having
trouble with testing :). It's close to finished, though, so I expect to
commit the code later this week.
-James
Warwick Burrows wrote:
James, thanks for the details on clustering.
The version of clustering that you're working on is a far better solution
than turning off caching on the servers. Will your modifications make it
into the 2.1 beta version? I really hope so as I don't think our product
will get the performance numbers we need with uncached servers :-/
Thanks,
Warwick
-----Original Message-----
From: James Mason [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 04, 2004 3:50 PM
To: Slide Users Mailing List
Subject: Re: Cache refresh notification in two different instance of Slide
running on different boxes.
Comments below.
Warwick Burrows 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.
When I say load-balancing isn't something Slide handles, I mean with a
cluster of Slide servers something else (a load-balancer) must decide
which requests go to which Slide server. Slide can't, and I think
shouldn't, pass requests to other servers in a cluster.
So what other features make up Slide's clustering implementation?
Slide currently supports "clustering" by pointing all your Slide
instances at the same Store, then disabling the global cache of each
Slide instance. This works, but without the global cache there is a
noticeable slowdown in the amount of time each transaction takes. What
I'm working on is a way to keep the global cache enabled and inform the
other servers in a cluster that their cache needs to be updated when a
resource changes.
And what is the underlying network transport for
the cache update notification events that are sent between the
servers?
The first implementation will use JMS, mainly because I've used it
before and I'm wanting to get this done before the feature freeze for
2.1. The ultimate goal is to use WebDAV notifications to send events
between servers. Unfortunately Slide doesn't support persistent
subscriptions for notifications yet, so it's not quite ready for this.
An acceptable alternative would be JGroups, but I've never used it
before, and as I said, I'm in a bit of a hurry :).
-James
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]
