You are correct - flushing query cache groups across the cluster with
JGroups (or something else) is a low overhead way to propagate
updates. My usual setup is to have post-update/remove/persist
listeners generate a distributed event with a cache group appropriate
for the object being saved. This allows to define flush granularity at
any level desired.
I don't have JGroups config specifically restricted to localhost,
however I haven't seen any problems with network flooding with mine.
Unless you also have some security considerations, you can use
something like that:
UDP(mcast_addr=231.12.21.132;mcast_port=45569;ip_ttl=4;tos=0;mcast_send_buf_size=150000;mcast_recv_buf_size=80000;bind_port=20000;port_range=500):PING(timeout=2000;num_initial_members=3):MERGE2(min_interval=5000;max_interval=10000):FD_SOCK:VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(gc_lag=50;retransmit_timeout=300,600,1200,2400,4800):UNICAST(timeout=300,600,1200,2400):pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;shun=false;print_local_addr=true)
Andrus
On Sep 23, 2009, at 4:34 PM, Malcolm Edgar wrote:
Hi All,
I am looking to improve the performance of a set of web applications
running. We have one application which is used mainly for
adminsitration/configuration and a number of public facing web
applications
which can have a high load.
I have been experimenting with OSCache but the problem I see is that
the
query cache and the object cache are not unified, so I sometimes have
situations where the objects from the caches are not consistent.
While the
query cache can timeout, the object cache doesn't, so if another web
application makes an update the object cache in this application is
not
updated.
I presume the answer to this problem is using JGroups, if so does
anyone
have a configuration where its constrained to localhost. I don't
really want
to be broadcasting notification messages across the network.
regards Malcolm Edgar
