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: JCS Setup Questions
Date Sun, 06 Mar 2005 20:20:19 GMT
Hi Daniel.

A removeAll sends one message, not a message for each
item.  

Jgroups is fine, but it is slower than the otehr
options.  

I'd use tcp lateral connections or the remote rmi
server.

If you use the tcp lateral, then you need to specify
the servers a cache should connect to.  If you have 3
servers, A, B, and C, then A should point to B and C, 
B should point to A and C, . . .

The problem is that this would require that you have a
different war for each app.  

There is asolution.  Use JNDI and a startup servlet. 
Set the server list as a value in applicaiton context
through the container.  Make a startup servlet that
configures JCS based on a properties object.  Load the
cache.ccf file and change the values you need.  Then
configure JCS with this. use the
CompositeCacheManager. 

This way you can deploy the same war to multiple
servers.  


Aaron

--- Daniel Rosenbaum <drdan321-nospam@yahoo.com>
wrote:

> Hello,
> 
> JCS seems to have come a long way since about a year
> ago.  Could
> I assume most of the bugs were fixed that the
> Hibernate project
> was reporting?
> 
> Anyhow, I am thinking about using JCS for it's
> clustered cache
> capability.  I hope the community would not mind
> giving me a few
> pointers how to set this up properly, and some
> insight as to
> what configuration options are best for me.
> 
> I have a web app running on Weblogic that is
> currently clustered
> on two servers but may go up to 5 servers or more. 
> The data I
> cache is mostly read only but changes occasionally. 
> I don't
> care so much about sharing data between servers but
> am more
> concerned about not serving stale data, so I would
> be happy just
> to send an invalidate message to the rest of the
> servers on an
> element change so they would not serve stale data.
> 
> I am trying to make heads or tales of the docs but
> find them
> difficult to understand.  As far as I could tell
> though a
> lateral cache would suit my needs best.  
> 
> 1) Since I am not so concerned about sharing the
> data I figure a
> remote cache is not so important, plus it seems for
> a remote
> cache I would need to start another process besides
> for the web
> servers.  This seems like overkill.  Am I correct
> though that
> for a lateral cache I would not need to start
> another process? 
> But if so I am confused how the "listener" gets
> started for a
> lateral cache, what sets up binding of the port etc.
>  The doc
> was not clear on this.
> 
> 2) I am unclear how I would specify servers in the
> properties
> files.  Could I use the same .ccf file for each
> server, or do I
> need to create a separate one for each server.  For
> example, say
> my servers as S1 and S2.  Could I simply put:
> 
>
jcs.auxiliary.LTCP.attributes.TcpServers=S1:1111,S2:1112
> 
> and include this .ccf in the war file running on
> both servers,
> or do I need to create one .ccf file with:
> 
> jcs.auxiliary.LTCP.attributes.TcpServers=S2:1112
> 
> to be in S1's war file and 
> 
> jcs.auxiliary.LTCP.attributes.TcpServers=S1:1112
> 
> to be in S2's war file?  And if I could just have
> one .ccf file
> for both servers, wouldn't this result in the server
> sending a
> message to itself (besides for the message sent to
> the other
> server) which it would then need to handle?  This
> seems
> wasteful.  On the other hand, I would not want to
> have to create
> a separate war file to be deployed for each server
> with a
> different setting in the .ccf file.  I have a
> feeling I just may
> be misunderstanding how this all works.
> 
> 3) Any advice what transmission mechanism to use for
> the lateral
> cache?  I am leaning towards using JGroups for the
> reliability. 
> Just a question about this though, does JGroups send
> the
> invalidate messages right away?  I think I remember
> reading
> somewhere that JGroups channels only work on a pull
> method, so
> servers only wake up every so often to get new
> messages, but
> messages are not received instantaneously.  Is this
> at all true?
>  I hope not, as I would want invalidate messages to
> reach all
> the servers as soon as data is changed.  If this is
> true, any
> advice how else to configure the lateral cache so
> that messages
> would be sent and received right away?
> 
> 4) Is there a way to set up the lateral caches to
> only send
> invalidate messages but not serialize the objects
> and send them?
>  My objects sometimes get pretty large so I would
> not want to
> incur the expense of this.  I'd rather servers get
> their own
> copies in the uncommon event more than one user
> needs the same
> data.  (most users in my app do not access the same
> data, but
> one user typically would access the same data over
> and over
> again in their web requests, and I am using a sticky
> load
> balancer so most of the time a user would hit the
> same server.)
> 
> 5) I will be using this cache with Hibernate.  For
> some reason
> the Hibernate project deprecated the use of JCS as a
> secondary
> cache, but I see no reason why not to, with all the
> bug fixes
> lately.  Does anyone know why not to?  The only
> thing I saw is
> not to use the JCS distributed cache functionality
> with
> Hibernate since JCS does not support locking, but I
> am not so
> concerned about this.  Is there any other reason?
> 
> 6) Am I correct to assume that if I call
> cache.removeAll() that
> all the elements in that cache region will be
> cleared on all the
> servers through the lateral cache?  Is this also
> efficient, say
> only one network message to clear the entire cache,
> or would JCS
> have to create a separate message for each element
> in the cache?
> 
> 7) Any other advice or alternative setups?
> 
> I know these are a lot of questions but I would
> appreciate any
> help.  Once I understand this better, in return I
> would like to
> give back to to community by perhaps contributing
> better
> documentation, or writing a proper user's guide.
> 
> Thank you,
> Daniel Rosenbaum
> 
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> turbine-jcs-user-help@jakarta.apache.org
> 
> 


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


Mime
View raw message