Remote failover is not fully implemented, although the remote server
works great as a distribution plugin.
When you run JCS you create regions. A region is a place where elements
are stored. You can have multiple regions. Each region can be given
different default behaviors. Each element in a region also has
configuration parameters. Most of the time an element will take default
values that you establish for a region.
All the gets and puts for a region are managed by a hub. You can add
auxiliaries or plugins to this hub. Each hub must have a memory plugin.
Basically, if all you need is simple memory caching, then you use JCS
with just a memorycache. All the other features of JCS are just unused
and should not create any extra overhead. These features are just
available incase you ever need them.
Auxiliaries come in 3 types: (1) memory, (2) disk, and (3) distributed.
You can choose a non default memory manager of your own choosing, but
the LRU implementation is very fast. I experimented with several disk
auxiliaries. Some of them are in the experimental code base. The best
disk cache is in the main code base. It's the indexeddiskcache.
Currently a disk cache only receives elements when the memory reaches
its maximum number of elements. I may make this configurable, so people
can create a redundant disk store. There are several distributed
auxiliaries. Many of them are in the experimental section. In the main
code base you have a choice between lateral distribution or remote
distribution. Basically the lateral distribution broadcasts elements
via tcp to other instances of JCS. It is generally configured only to
broadcast and not get. When an element is put in the cache it will be
sent to all other lateral caches in its configuration. The remote sever
is a centralized server that all the locals connect to. Local caches
are usually configured to send puts to the remote sever which then tells
the other local caches to remove that item. Then if a local cache needs
an item that it doesn't have, it will go to the remote sever looking for
it. The remote sever can be configured with other auxiliaries, most
likely a disk cache.
Get requests go in this order: memory, disk, distributed. If memory
doesn't have it then it checks disk and so on.
Put requests work like this. Put to memory and all non disk auxiliaries
(of course this is configurable by region, element, and auxiliary). If
memory is full then put the least used item to disk if there is a disk
configured.
More documentation is on the website.
Aaron
-----Original Message-----
From: Natekar, Leena (Cognizant) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 18, 2003 9:12 AM
To: [EMAIL PROTECTED]
Subject: JCS in cluster environment
Hi,
I am new to JCS and just exploring clustering...
I would like to know how JCS behaves in a cluster environment. I
understand from the documentation that I can configure a Remote
auxillary cache for Failover( cache.ccf configuration).
What I would like to know is
1. If disk cache is configured along with the remote auxillary cache
then objects will be written to local disk after the in memory objects
are more than the max limit. When would they be stored on the remote
auxillary cache ? Does the client conitnuosly broadcast the cache
updates to the servers?
2. In case of a failure of client, would the in memory cached objects as
well as the objects written to the local disk be replicated ?
Thanks and Regards,
Leena.
