Sorry Aaron (or anyone), one more question.... The Plugins page mentions a BerkleyDB JE auxiliary, but I cant find it mentioned anywhere else.
What is it called and where do I find the docs on using it? Thanks On Tue, Aug 11, 2009 at 10:47 AM, Aaron Smuts <asm...@yahoo.com> wrote: > > 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 > > -- ~~ Microsoft help desk says: reply hazy, ask again later. ~~
