That's the eviction thread wake up interval to process eviction.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925885#3925885
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925885
Ok, it is diffcult for me to see now because I have run some profiling myself
last week and I didn't see it. Which version of JBossCache you are using?
-Ben
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925888#3925888
Reply to the post :
I don't think you have answered my question. Do your MBean has put a explict
dependency on TreeCacheMBean?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925890#3925890
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925890
yes it has descriptor
depends optional-attribute-name=CacheNamejboss.cache:service=SessionCache
where jboss.cache:service=SessionCache is the name of TreeCacheMBean
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925896#3925896
Reply to the post :
What JBossCache version?
The problem you describe is so fundamental that it's hard for me to even
imagine what it might be. If you can create a simple test case that
demonstrates this and attach it to a new JIRA, I'll take a look. Please make
the test case entirely self-contained; I don't
I've seen this problem, caused by having another JBoss machine on the same
network, using the same mcast address and port, but a different partition name.
Remember also that the all configuration creates two cluster partitions, one
defined in cluster-service.xml, the other in
Do you mean to say if in this period the node is not accessed it will be
evicted.
In the test cases dealing with wakeUpIntervalSeconds you have used a method
called _sleep(period ) where the period depends on wakeUpIntervalSeconds. How
is this going to affect the performance of the test case.
Here in the Code pasted below what I have seen is that the value of the node
/aop/3 is null if it is not processed in the last 9.950sec. The value given for
the wakeUpIntervalSecond is 5 sec and for the timeToLiveSeconds for region /aop
is 4 sec.
When I access the node /aop/3/1 even after 13
Are your keys, that you use in cache, of type String or of some other type. Was
just wondering if this has got something to do with the equals method of your
key.
Also,
cache.put(/X, yourKey, A);
| Object previousValue = cache.put(/X, someOtherKey, B);
What does previousValue hold in this
Hi Ben!
I'm using a homegrown session manager because I can't set the subdomain cookie
scope on Tomcat's sessions (long story). I create a session once and put it
into the cache with putObject(). The key I use is a unique string generated
from the request (url + subdomain + some other
So you're saying if you do this:
| cache.put(/X, A, A);
| cache.put(/X, B, B);
| Object result = cache.get(/X, A);
|
You're getting B for result?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925733#3925733
Reply to the post :
and did your MBean have a explicit depency on TreeCacheMbean?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925355#3925355
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925355
The first question is how do you the TreeCacheAop? Do you use putObject()
inside your session for every request? If it is, this may be the problem since
it is slow (and should be used only initially).
Also, if you use web clustering, we will support fine-grained replication in
4.0.4 (using
Yes. it's working in single machine.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3925395#3925395
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3925395
---
This SF.net
It happens right after state transfer. I can dupliate
the problem.
Seems there is a race condition, where the MBean has not
yet finishing reading evict policy config at that time.
I created the cache in startSerice():
protected void startService() throws Exception {
if (cacheName == null)
I got same problem when runing two machine clusters
and I can duplicate the problem.
It happens when
1) machine A is up running
2) there are requests comming to the cluster, so the tree is being updated.
3) In the middle, Machine B is restarted.
The LRUPolicy in machine B got
Sorry I mean I am running JBOSS TreeCache 1.2.3
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3924707#3924707
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3924707
---
my Eviction config is as follows:
org.jboss.cache.eviction.LRUPolicy
10
!-- Cache wide default --
2
0
Are you saying this error happened during Machine B's restart? If it is, it is
weird because state transfer should not trigger the eviction yet.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3924734#3924734
Reply to the post :
Changing the BoundedBuffer to this:
| nodeEventQueue_ = new BoundedLinkedQueue(RegionManager.CAPACITY);
|
should reduce memory. Probably Region should allow the Channel implementation
to be configurable.
View the original post :
Correct. We hook into the 2PC, and if our PREPARE phase fails, the *entire* TX
will roll back
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923815#3923815
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3923815
Ok thx.
Does JBossCache offer a fully fledged XAResource? Or is it just hooking in via
the Synchronization interface?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923915#3923915
Reply to the post :
The latter. The former is on the todo list
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923922#3923922
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3923922
---
This
I am experiencing the same problem on Oracle application Server 10g-R2. We have
JBoss Tree Cache implementation and our J2ee application joins the tree cache
which is published by another process mostly on separate machine. We are using
TCP mode of communication.
I am getting following
My system has many different types of data and I need them to expire at various
times. Some things I need to expire in 10 minutes, other things after one
hour, others after 12 hours. The objects are also not grouped as packages that
the parent can have a policy, but all of my hibernate POs
I'm wondering if you could solve your problem by implementing read/writeObject
as follows:
| private void writeObject(java.io.ObjectOutputStream out)
| throws IOException
| {
|out.writeObject(itemCode);
|out.writeObject(description);
|out.writeBoolean(defaultItem);
I think Brian's suggestion should work to explicitly define your own read/write
external. If true, this is brilliant! :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3924102#3924102
Reply to the post :
hi Ben,
Thanks alot for your response, my question would be if we n't able to transport
PoJo cached object how people are working around that. So if am n't wrong, we
need to use PoJo when we need to use cached objects in middleware only.
I really want to take pros of PoJO cache, if that is
Unfortunatly I don't have access to JProfiler. However I notice that a new
Object[] array seems to be allocated for each Region defined, so it is not
sufficient to create a test case that allocates only one array. My application
has eviction policies on over 50 different regions. Might this
My understanding of these terms is that Hibernate defines 4 cache types --
read-only, read-write, non-strict-read-write, and transactional. Transactional
allows reads and writes and uses JTA transactions for coordinating access to
cache data. JBossCache is transactional. It certainly
Usually, the use case is everyone participates in the cluster replication group
as a peer. But I am not saying that it can't be done. Like I said, some form of
dettach/re-attach could work. But that probably would defeat the strength of
PojoCache since when detached, it won't be able to
Ok, that can be it then. Although there is no region limit, I don't recommend
using that many regions. Eviction timer thread would have to traverse each
region, that would probably be slow.
Why do you need this kind of fine granularity though?
-Ben
View the original post :
thanks..
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923357#3923357
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3923357
---
This SF.net email is sponsored by:
Ben,
Thanks for your reply. The numbers in my profiling here is only the amount of
memory used for the Object[] array with empty slots, I do not think it includes
any objects actually referenced by the array itself. In other words, it is
13600272 bytes just for having an Object[] array of
Oh yeah, I forgot to mention that I took this heap dump when the app was
initialized right after Hibernate was finished configuring. Nothing was even
placed in the cache yet at this point.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923430#3923430
Reply
Anu,
What you ae looking for is the detach/re-attach capbility of which PojoCache
does not have now (noy sure if it even makes sense though).
Is the plain TreeCache an option then?
-Ben
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923495#3923495
Reply to
I just created the following simple unit test:
public class MemoryTest extends TestCase
{
public void test() throws Exception
{
BoundedBuffer buffer = new BoundedBuffer(20);
Object[] a = new Object[20];
a[0] = foo;
a[10] = foo2;
buffer.put(abc);
Daniel,
TO answer your question. Yes, the queue size is too rigid. We do have a Jira
task to change that actually. But the total memory used by eviction should also
depends on your wakeupInterval. During your load test, if you eviction thread
wakes too slowly, you will see the node event
Have a look at http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheCacheLoaders
- which initially describes the new configuration elements for cache loaders in
JBoss Cache 1.3.0, and then talks about the architecture of cache loaders in
1.3.0, including the ability to chain cache loaders.
[EMAIL PROTECTED] wrote : Details at http://www.jboss.com/products/jgroups.
|
| This should be API-compatible with JGroups 2.2.7 and 2.2.8, but we haven't
yet tested it with JBoss 3.2.x and 4.0.x. You can replace your jgroups JAR with
the one from 2.2.9beta, but this is not yet officially
Are you running in the JBoss appserver? If see, JBoss Cache based session
replication is standard; all you need to do to use it is run the 'all' config
and add an empty distributable element to your web.xml.
To answer your question, #2 is the only workable solution. Locks are obtained
at the
That helps. Thanks
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923111#3923111
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3923111
---
This SF.net email is sponsored
Hi Ben,
Thanks for your reply, if I make Answer as non-serializable I need some of way
of sending Answer contents in Serialized object. I don't have any control over
client whatsoever, they are using TeamBridge(no Idea what it is) but it's main
requirement is they need serialized object what
Should we add export functionality to JBoss Cache 1.4? I'm thinking that we
could have a way to:
1. Return set of keys at a specified fqn
2. Return set of values at a specified fqn
3. Return map of keys/values at a specified fqn
I might be able to use this functionality to improve the
It seems that with the 1.2.4SP1 the above error not ocures.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922970#3922970
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922970
JBossCache is not used for the Hibernate session (i.e. L1) cache. If you've
determined that this has nothing to do with JBossCache as a L2 cache, you're
better off posting on the Hibernate forums.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3923038#3923038
Sure, just leave the TransactionManagerLookupClass attribute blank. You'll get
a log WARN about running w/o transactions, but that's it.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922594#3922594
Reply to the post :
Thank you,
It works now.
/BJ
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922601#3922601
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922601
---
This SF.net email
Awesome. Initially I wanted to try OSCache found few not good reviews online.
And then I checked JBoss Cache. The implementation suits my needs. And since
you guys are part of JSR 107 which adds more credibility to JBoss Cache.
Do you guys have any expectation on when 2.0/JSR 107 compliant one
Hi Ben,
I have the following POJO class which needs to be apectized and has to send
over wire to client.
Code:
| import java.io.Serializable;
| import java.util.ArrayList;
|
| /**
| *
| * @@org.jboss.cache.aop.AopMarker
| */
|
| public class Answer implements
Thanks. I have no idea when JSR 107 will be out, there's not much work going on
right now.
I'm guilty myself; I'm just so swamped I cannot find time to contribute much !
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922624#3922624
Reply to the post :
Hi Folks,
one more thing to add.
I want to cache Answer object which is structured as above but I need that to
be serializable since for front-end their system won't work if objects are n't
serizable.
My question is can I make this class as seriazable and still use Tree Cache
AOP. If I
Hi Ben and Bill,
Bill you said Tree Cache AOP is working fine for serialized objects, but I have
weird problem though. I am using Jboss Tree Cache AOP 1.2.4, I made serialized
classes as apectized and placing them in TreeCacheAOP. By going through docs I
realized that I need to have my
1. You don't need Anser to be Serilaizable to run TreeCacheAop.
2. But I assume you are transporting Answer object between your client and
erver? This won't work since the Answer object is aspectized, meaning it has
additonal CacheInterceptor attached (and therefore not Serializable).
Thanks - Is there any other alternatives to this or is my only option to write
a routine to walk to tree ?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922297#3922297
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922297
In other words - Is there a way to dump the contents of the cache into a flat
file or something that I can parse?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922300#3922300
Reply to the post :
Hi, Any updates when JBoss Cache will be JSR 107 compliant?
Thiru
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922356#3922356
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922356
Hi Guys,
I finally make CacheAOP to work as MBean in JBoss 4.0, my jboss-aop.xml
aspectized configuration file is
1. jboss-aop.xml
?xml version=1.0 encoding=UTF-8?
| aop
|!-- This is declaration file for annotation. We are using JDK1.4 now,
| so an annotationc pre-compiler is
Removal refers to removing old data, including the underlying data store.
Eviction is for removing from memory but maintaining the data on disk.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922384#3922384
Reply to the post :
Removal is removing a node from the tree by the user on demand whereas eviction
is automated remval of nodes based on the configured eviction policy. The
eviction policy could be age based or time based. JBossCache has several
eviction policy to choose from. Also, you can write your own custom
You need to use JTA transactions. JBossCache's transactional support is based
on JTA transactions; it has no knowledge of non-JTA Hibernate transactions.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922408#3922408
Reply to the post :
Unfortunately JSR 107 is not yet out, so JBossCache cannot be compliant. We
intend to make changes to the API of JBossCache for the 2.0 version to align
ourselves with the draft API of JSR 107, so that when the JSR is final we will
be able to provide a compliant version soon afterwards.
View
No. But please open up a Jira if you deem this is needed.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922457#3922457
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922457
Yes, you can do that. Or you can grab it from cvs.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3922078#3922078
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3922078
No, what you mean is *passivation*: when the cache is full, elements are
evicted and save to a store. When accessed again, they're fetched from the
store (removed from it) and placed into memory again.
CacheLoaderChaining is a different beast. What it provides is the ability to
attach a cost
Maybe we should change the default behavior to *not* drop the table...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921789#3921789
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921789
Seems like cache loader default persistence should be consistent, or at least
better documented so that it's more clear.
I can look at the documentation on this subject and clean it where appropriate
so that this behavior is better described.
View the original post :
Sorry, no. You'd have to walk the tree.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921957#3921957
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921957
---
This
anonymous wrote : If there were a way the CachedSetImpl could know if members
have been added or removed due to replication, then the map could be kept
up-to-date and the scan avoided.
For JBCACHE-354 (http://jira.jboss.com/jira/browse/JBCACHE-354) to be
completed, I think there will have to
It looks like there is already a map maintained that we could try to use.
Although, it maps Key to Object, I could probably use it to speed up the
iterator. Our current iterator is getting the set of of keys and does a lookup
on every call to Next.
I think that the lookup is hashed and
anonymous wrote : I think that the lookup is hashed and should be fast,
however, it might be faster to have our iterator get the set of all values in
the map instead.
|
| I'll try this and see what kind of values I get out of it.
This looks promising, adding 2000 entries only took about
1. This is an oversight. I have fixed that.
2. The requirement to use String as a key is to avoid the recursive loop in
Map. It is probably ok to use Object in Set
3. We have discussed to provide different kind of implementations in the future.
4. In the case that Key is non-primitive, we
do you set the shared flag to true when you configure the cloader?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921479#3921479
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921479
I didn't have a shared setting; I guess the default value is false. I added
a shared=true setting to my configuration and the problem disappeared.
Thanks.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921481#3921481
Reply to the post :
I took the latest source and ran the testsuite against my new CachedSetImpl and
I'm getting a stack overflow. I need to adjust to the adjustment that you made
(I'm guessing). :)
Caused by: java.lang.StackOverflowError
at
No, looks like I was wrong, it wasn't your change. You only changed Map
handling.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921522#3921522
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921522
I'm past the stack overflow and on to the next error. :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921589#3921589
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921589
[EMAIL PROTECTED] wrote :
| 4. In the case that Key is non-primitive, we shall require them to be
Serializable. I think this is in line with regular POJO Cache where we require
the POJO to be aspectizable (.e.g, with xml or annotation declaration),
otherwise, it needs to be Serializable.
|
Brian,
Your right of course, I'm getting fast performance locally but I'm guilty of
double buffering the data in the same network rpc call (and then some).
I could omit the data field and only pass it in the key but that would be too
coarse grained (the entire value would be passed in the fqn
I don't think the hashed search will work either.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921629#3921629
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3921629
---
I'm half-asleep and this is half-baked, but want to write it down before I
sleep and forget about it :) Luckily I have the power to delete posts, so if I
wake up, read this and am embarassed, well poof!
Use integers as keys. In CachedSetImpl add a field
private MapObject, Integer
Best way is to get the JBossCache source and compile them in 1.3 yourself. But
please keep in mind that we don't officially support 1.3.
The other option is to get jboss-cache.jar from 3.2.7 release. It was
compatible in 1.3 but it is an older (and modified) version of JBossCache.
View the
I have a newer implementation of CachedSetImpl that improves the performance
for add + iteration, however, I need to resolve the following questions
before proceeding.
1. For Map, I think that we convert the key to String in one place but not the
other.
CollectionClassHandler computes
Thank you;
but in
http://www.jboss.com/products/jbosscache/downloads
there are sources only for 1.2.4 version of JBossCache. May I compile them
under JDK 1.3?
thank you again.
matabo
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3921313#3921313
Reply to
What I tend to do when running such tests is to give it a few 'warm up' loops
(perhaps 2000) for the JIT compiler to come up to speed - I've noticed this
irons out inconsistencies. I usually then run the test with about 10,000
loops...
Either way though, even if there isn't a performance
You could use a startup class that starts the TreeCache and binds it in JNDI -
then other 'consumer threads' could look this up in JNDI.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920893#3920893
Reply to the post :
1) Yes, you can do this.
2) Yes, it will work provided you can adhere to the CacheLoader interface
methods and provide the symatics expected of a CacheLoader implementation.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920895#3920895
Reply to the post :
It should - what version of JBossCache are you using, the exception should
print out how many seconds it waited before it threw a TimeoutException ...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920896#3920896
Reply to the post :
Nope. If you need to maintain integrity in the event of a failure when using
replication, we'd recommend using transactions...
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920897#3920897
Reply to the post :
Yes, it definitely fixes a major bug and I have checked in the donated patch
which resolves the bug.
I have some longer term performance changes that I'm working on for
CacheSetImpl.
Before my longer term changes:
1. Calling add 2000 times in a loop took 39.816 seconds
2 Performing 2000
I am using Jbosscache1.2.3. It prints the exact exception which I have posted
here. To determine the time taken before it throws the exception, I had put
debug statements in my code..before the put statement and in my catch block
in the 2nd servlet. This time difference was 30s. Thanks.
View
[EMAIL PROTECTED] wrote : It's great you're already pushing this with 1.3.0,
Manik.
Integration woes, great? I don't think so! :-)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920723#3920723
Reply to the post :
I compared the performance of this new implementation against what I checked in
on December 5th 2005 and don't see much difference:
December 5th changes:
1. Calling add 2000 times in a loop took 39.816 seconds
2 Performing 2000 iterations in a loop took 39.329 seconds
With the new
So for iterating over the set, the new code was actually slower! That's not
good :(
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920841#3920841
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=3920841
I would say that performance was about the same as the results almost always
vary (I didn't repeat the test enough times to get an exact measure).
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=3920855#3920855
Reply to the post :
Ok, I've fixed this in HEAD. Expecting to hear from QA with this problem in
1.3.0.DR1 any minute now! :-) We do need some integration tests, the question
is where should such tests reside. I dare say they should be in the AS test
suite. And such tests probably already do exist in AS.
I
I found out what the problem was. I had to swap the two ip addresses.
Had
| TCP bind_addr=168.192.0.10 start_port=7810 stop_port=1
loopback=true/
| TCPPING initial_hosts=168.192.0.10[7810],168.192.0.33[7810]
port_range=3 timeout=3500
| num_initial_members=3
The fix seems to be fine. At least my own sample code having transactions in a
replicated cache now works. :)
re: the multiple instance issue - I recently modified the interceptor mbean
registration code so that the mbean will only be registered if not already
registered. So the server
I've just tried using two clustered cache instances on a single server and it
seemed to run fine. I created the second cache configuration by copying the
first and then modifying the service name. The instances were registered
properly and replication worked as expected.
View the original
[EMAIL PROTECTED] wrote : Ok, I've fixed this in HEAD. Expecting to hear
from QA with this problem in 1.3.0.DR1 any minute now! :-) We do need some
integration tests, the question is where should such tests reside. I dare say
they should be in the AS test suite. And such tests probably
501 - 600 of 1881 matches
Mail list logo
