Dear Jeffrey, You might want to read the remote cache docs. Some of you questions are answered there.
1. Your description of what JCS can do is somewhat right and somewhat off. JCS doesn't have the concept of a master, exactly. But you can configure it to look something like what you are interested in. You can chain remote cache servers. In a high get / low put situation you could have some clients connect to some set of the remote servers. This way you could distribute get traffic between the remote servers. This would allow you to scale quite a bit. But it still requires replicating the data. So it's not the best way to scale for huge installations. I'll come back to that. In this configuration, let's say that you have 4 remote servers: A, B, C, and D. You configure A to have remote auxiliaries for B, C, and D; B for A, C, and D . . . Items that are put to A would also be sent to B, C, and D. . . . You could then divide your clients among the servers. You can include a list of servers in your client configuration. The remote client will try to connect to them in order. The first in the list will be considered the primary. JCS will try to restore the connection to the primary if it goes down. In the meantime, it will connect to failover. It will go through the list looking for a working failover. Say you have 4 clients: 1, 2, 3, and 4. You'd configure 1 with a list like this: A,B,C,D; 2 with a list like this: B,C,D,A; 3 with a list like this: C,D,A,B . . . Client can register listeners or not. You want to register listeners if you want to receive notification about changes. You need to do this if you store volitile data on the clients. Otherwise, don't. It can create a lot of chatter if there are lots of puts. 2. Remote servers do not replicate on startup. They will fetch data on demand. If A goes down, client 1 will connect to B. When A comes back, client 1 will reconnect. Depending on the data store, A might be empty. If so, if A is asked for an item that it doesn't have, it will ask B. If it gets the data from B, it will store it. 3. JCS uses event queues througout. There are multiple places where you can configure the internal threadpools used by the pooled queue type. If you want, you can inject your own queue. In one installation, I do just this. I have my own event queue that uses a custom thread pool that copies thread local data. 4. If you don't have the clients listening, then you should be able to scale quite a bit. The number of clients connected isn't as important and the number listening. There is also an http remote client and server. You could simply direct your clients through a load balancer that would spread out the load without all the manual configuration. . . . I have a big installation that uses a different strategy for handling a tremendous amount of data. I partition the data. I have numerous pairs of remote servers that handle only a small subset of the data. I could scale it to the network limit and then partition the network . . . Aaron --- On Mon, 8/10/09, Jeffrey Kesselman <jef...@gmail.com> wrote: > From: Jeffrey Kesselman <jef...@gmail.com> > Subject: Some preliminary JCS questions > To: jcs-users@jakarta.apache.org > Date: Monday, August 10, 2009, 5:18 PM > Hi, > > Im looking at maybe using JCS as the guts of a game > resource database > distribution scheme. I need a couple of questions > answered to determine ita > suitability. > > (1) I understand that JCS can have effectively master > caches, to which thing > can be added, and remote caches that are read only and get > updates friom the > master(s). Am I correct that there can be more then > one master and that > they can replicate updates to each other? > > (2) If a remote cache is disconnecetd or shut down for some > period of time > and then brought abck online, will it sync with its > masters' current > contents automatically? > > (3) Im looking at perhapse bulding the master into a larger > framework that > already has a thread management model, How does JCS > use threads? Does it > multi-thread? If so, can I get control over therad > allocation opr is it > buried deep in the code base? > > (4) How does it scale in terms of connectind remotes? > Updates I am > expecting to be infrequent, but I am expecting thousands of > remoptes > connected to each master. Do the remtoes all have to > connect to one master > or can the remotes daisy chain? If they can daisy > chain, how do the > discover each iother and what do they do if their parent in > the chain fails? > > Thanks > > -- > ~~ Microsoft help desk says: reply hazy, ask again later. > ~~ > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-users-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-users-h...@jakarta.apache.org
