jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Smuts <asm...@yahoo.com>
Subject Re: Some preliminary JCS questions
Date Wed, 12 Aug 2009 14:00:25 GMT
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 <jeffpk@gmail.com> wrote:

> From: Jeffrey Kesselman <jeffpk@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 <asmuts@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 <jeffpk@gmail.com>
> wrote:
> >
> > > From: Jeffrey Kesselman <jeffpk@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-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> >
> >
> 
> 
> -- 
> ~~ Microsoft help desk says: reply hazy, ask again later.
> ~~
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org


Mime
View raw message