Thanks for your suggestions!
For this I have a question:
anonymous wrote : No, the id is purely the FQN.
It sounds like one FQN is associated to only one pojo that is attached with the
string id. There cannot be multiple pojos (we do not count the nested inner
pojos of one attached pojo) under
With regards to the performance issue, please send me several thread dumps
taken with 30s-1m difference each using the kill -3 or Ctrl+Break method
explained in http://www.jboss.org/community/wiki/StackTrace and enable garbage
collection logging
niuxuetao_fiserv wrote : I just realized that since I am using Pojo cache, I
am not sure how Pojo cache creates the FQN when I pass a string id to the
PojoCache.attach(String id,Object obj).
|
| Suppose I pass id as X/Y what FQN will be really created?
|
| What will be the performance
I just realized that since I am using Pojo cache, I am not sure how Pojo cache
creates the FQN when I pass a string id to the PojoCache.attach(String
id,Object obj).
Suppose I pass id as X/Y what FQN will be really created?
What will be the performance impact if I have 10-20 variations of X
Now I have a very serious performance problem with the way (the X/Y way) I
compose the string id when using Pojo cache.
I have one PojoCache instance globally shared by 20 threads in websphere, but
those 20 threads are mostly in the waiting state by what I see with
JProfiler, the hotspots are:
I mean the healthy concurrency situation I would expect to see is that at least
one thread is busy at ANY moment.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4244945#4244945
Reply to the post :
The stack trace of the waiting thread is below:
| org.jboss.cache.util.concurrent.locks.OwnableReentrantLock.tryLock(long,
java.util.concurrent.TimeUnit)
| java.util.concurrent.locks.Lock.tryLock(long, java.util.concurrent.TimeUnit)
|
Thanks Galder!
I doubt managing the number of nodes can greatly increase the difficulty of our
implementation or deployment when we use Pojo cache. Or perhaps it is even not
doable to dynamically manage the node numbers?
I am wondering if there is a jboss product (perhaps infini-span) that
Right, I suspect that your lock timeout issues might be related to your current
fqn structure. If you bear in mind that locks are acquired on a per FQN basis,
storing a lot keys within an FQN leads to lock contention. Instead, I'd suggest
you add more FQNs and reduce the number of keys stored
How many A objects do you expect to have in the system? Are all A objects
stored under the same FQN?
Also, of those A objects, take for example instance A1. Are you calling
multiple attach/detach for the same A1 instance? Or for each A instance, i.e.
A1, there's only one attach and one detach?
We use about 10-20 nodes (i.e. 10-20 different FQNs) and each node keeps up to
1000,000 keys in the map, so each node/FQN also keeps up to 1000,000 instances
of A.
For A1, I am calling attach() and detach() only once respectively.
View the original post :
Thanks a lot Galder for your help!
What I need from Pojo cache is that it returns the same reference of object
with the same fqn under the same node, which is what jboss core cache probably
cannot do at the moment.
Do you know any way to use jboss core cache with the reference comparability
niuxuetao_fiserv wrote : About the write-intensive stuff, yes, we will have a
lot more calls to attach() than modifying the already cached Pojos.
Attaching a pojo is an expensive operation where the pojo is dissected and
mapped to the cache, hence such operation should be used as less as
Thanks for your reply Galder!
I couldn't reproduce the deadlocking problem on my windows machine anymore
(with a rather large number of lockWaiting time config), I am trying on Linux
where it does happen randomly.
About the write-intensive stuff, yes, we will have a lot more calls to attach()
First of all, to generate thread dumps and see where threads holding write
locks might be stuck, see generating thread dumps wiki:
http://www.jboss.org/community/wiki/StackTrace
I must say that 100ms for lock timeout is pretty small. Something around 10-20
seconds is more usual. Rather than
Anyone has an idea?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239410#4239410
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4239410
___
jboss-user mailing list
How big are the Pojos that you're storing? Several kbs/megs...etc?
Did you try getting some thread dumps to see what the thread holding the lock
to the database is doing?
Can you try commenting preloading and trying again?
View the original post :
Maybe something useful to give:
Now I use 20 threads doing the same job (setting
ockAcquisitionTimeout=4294967, all the rest configuration is the same as I
pasted before), I experience a phenonemen which seems to be a true deadlock
since no threads are running (jobs in the Threadpool
Hi Galder,
Thanks for the hints to probe the problem!
The size of a Pojo is between 5k and 100k by estimate.
I did not track the lock-holder thread's behavior, cuz I do not know how to do
it, could you give some tips on this?
I disabled the preloading and I haven't seen the berkeleyDb
P.S., I am sharing one org.jboss.cache.pojo.PojoCache instance amongst multiple
threads.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4239191#4239191
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4239191
And, this is my class which should have the cache object fully initialized
within the constructor:
| private final PojoCache cache;
|
| JBossPojoCacheStorage(Configuration config){
|
|
| cache =
21 matches
Mail list logo
