If the question is is cached data removed when stopService/startService are
called, the answer is no, the cached data is not removed.
I did experience and issue after a cache restart, where the LRU policy was
not functionning properly (node that were supposed to be evicted where not).
I did
It is not removed from the memory.
You probably need to do something like that:
1) stopService
2) empty the cache (you can probly use the regular operation to empty the
cache, I suspect that since the cache is stopped, there will be no replciation
going on).
3) startService.
The other option
remove methods.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3864664#3864664
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3864664
---
This SF.Net email is sponsored
Eviction policy is what you are looking for, I think.
JBossCache provides a default LRU implementation. the time-to-live is not set
per object you insert in the cache, but per region.
Check eviction policy in JBossCache documentation.
Thomas
View the original post :
I think this can be all implemented as an eviction policy.
The only thing that cannot be implemented using the eviciton policy is the ttl
per node, unless you come up with a specific nming convention for the node and
provide the ttl in some other ways (such as through the configuration of your
Thanks for the pointer.
In my case, I do not have any JDBC driver jar in my ear.
But I suppose that putting the JBossCache jars (the error is occuring on a
JBossCache class) in the server/lib instead of the EAR will solve the problem.
I do not like the idea too much as I'd like to have my EAR as
I did not find a way to fix it.
May be with class loader scoped ear, but I am not sure (I did not try).
Thomas
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862940#3862940
Reply to the post :
I guess I do not have a precise use case in mind, only some performance
questions in certain configurations:
1) In case where synchronous replication is required (I want all the node to
always be in synch after an update), just sending an invalidation message might
be faster (from an update
I went through the CacheLoader documentation of JBossCache1.2.
I was wondering if the following use case has been (or is being) considered:
cache distributed in a cluster, each nodes configured with the same CacheLoader
and backend storage. When an update is done in one of the node, the data is
Thanks for the answer.
Do we agree that this is something that must be done within JBossCache itself?
What I mean is that I do not see how someone could implement such mechanism
using only the current eviction policy plugin mechanism (or may be I can, but
ain't pretty .).
I did not find
Thanks.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3862253#3862253
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3862253
---
The SF.Net email is sponsored by: Beat
I do not think that JBossCache uses any weak/soft reference in its
implementation, so I wonder how one would implement an automatic eviction
policy using weak/soft reference so objects are removed from the cache only
when not referenced by anybody anymore (or something like that).
Can such
Thanks for the answer.
Is there something that I am doing wrong in my package to cause this issue?
This is happening upon the re-deploy of the EAR, so I am wondering why the
re-deploy is using a destroyed class loader instead of a new one.
Any suggestions on how I might fix it or is the JBoss
I do not think there are any differences between the two.
According to the documentation and CVS source tree, it seems to be a renaming
that occurs in JBossCache 1.2.
The timeToIdleSeconds in JBossCache 1.2 became timeToLiveSeconds in 1.2.
I am not sure what you mean by turn ON/OFF, but call to
I got the exact same error when using the new name with an old JBossCache
version (you have an old JBossCache package but you look at the latest
documentation).
Using the correct value for the correct JBossCache version solved the problem
for me.
Thomas
View the original post :
I have an ear application that is using JBossCache internally.
The JBossCache jars are packaged as part of the EAR (i'd like it to be portable
accross app server).
When doing a hot redeploy of my EAR, I am getting the following exception.
If I stop and restart JBoss, then everything works fine.
I have the impression that the LRUPolicy is not cleaning its eviction timer
properly after multiple stop/start on the TreeCache.
Here is what I am doing on an existing TreeCache:
| treeCache.stop
| propertyConfigurator.configure(treeCache, [new XML config])
| treeCache.start
|
The
Using TreeCache, it seems that all the configuration parameters can be
programmatically set (see list below).
For some of them, I saw a comment saying that if it is modified, the cache must
be redeployed.
I am trying to understand the following:
- Does the cache have to be redeployed if any
Great. Thanks.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3861128#3861128
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3861128
---
The SF.Net email is sponsored by:
I believe that in the JBoss terminology a Node is the the element identified by
a fqn.
When looking at the eviction policy and the TreeCacheListener interface, it
seems clear that eviction applies to a node as a whole and not to each
individual cached object in the Hashtable of such node).
All
Ben,
Thanks for the answers. I appreciate.
I think I found the post you mentioned about the class loader
(http://www.jboss.org/index.html?module=bbop=viewtopict=52082).
I will do a few tests as I need JBossCache to work in WebSphere and WebLogic (which, I
think have scoped class loader by
Sorry, wrong post reference.
The correct on, I believe, is
http://www.jboss.org/index.html?module=bbop=viewtopict=52056
Thomas
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3844799#3844799
Reply to the post :
I guess my questions do not make too much sense since nobody us replying :-)
I will try to do further research.
I'd like to add two more questions (hopefully these ones make nore sense):
1) Can I create multiple cache instances (multiple MBean instance for a TreeCache) and
that they all share
I am not very familiar with JGroups, but is there any particular advantages in
choosing which node of the cluster is the coordinator?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3844140#3844140
Reply to the post :
After a first read of the tutorial, FAQ and TreeCache documentation, I have a few
questions on JBossCache:
1) Locking: when J2EE transactions are used, I suppose that locking is done accross
all the nodes of the cluster. Is it correct?
2) I saw in the different post that XAResource interface
25 matches
Mail list logo
