Terrific, thank you VERY much. I think I have enough information now to design my architecture and start prototyping!
JK On Wed, Aug 12, 2009 at 10:00 AM, Aaron Smuts <asm...@yahoo.com> wrote: > There were licensing issues. I think BDBJE was LGPL. I can't remember. > In any case, if you want to use it, you can simply write your own auxiliary > and plug it into JCS. JCS is extensible. This wouldn't be hard. > > I've had much, much better performance using MySQL (4.something) running > the MyISAM storage engine. I run an instance on each remote cache box. I > often use a combination of mysql and indexed disk caches. > > JCS handles data expiration, notification, replication. . . . > > Aaron > > --- On Tue, 8/11/09, Jeffrey Kesselman <jef...@gmail.com> wrote: > > > From: Jeffrey Kesselman <jef...@gmail.com> > > Subject: Re: Some preliminary JCS questions > > To: "JCS Users List" <jcs-users@jakarta.apache.org> > > Date: Tuesday, August 11, 2009, 7:53 PM > > 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. > > ~~ > > > > --------------------------------------------------------------------- > 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. ~~
