"[EMAIL PROTECTED]" wrote : Can you enable this in Hibernate to see if that
solves the problem:
|
| hibernate.cache.use_minimal_puts
|
| Gavin and I have had a discussion on the potential problem. That, when
using query cache, Hibernate will do a put on the JBossCache while retrieving
Neither READ_COMMITED nor READ_UNCOMMITED help, only NONE which is
inappropriate.
I do not claim it's cache's bug, but it appears to be some design issue.
Let me explain. Suppose you have some read-only entity which is frequently used
through application. This is exactly where I expect to take
"[EMAIL PROTECTED]" wrote : So here's my understand how Hibernate uses the 2nd
level cache (disclaimer: I'm not a Hibernate expert).
| And I haven't read the docs yet...
|
| - 1st level cache is per Session. This is an Object-level cache
| - 2nd level is per VM, shared by all Sessions. Th
I'm not sure whether it is problem of cache, hibernate or my design. Please
give me an advise if there's a well-known pattern to solve this.
Suppose I have an entity with two props - key and value mapped to a table with
two fields.
|
|
|
|
|
|
"[EMAIL PROTECTED]" wrote : Can you open up a JIRA (jira.jboss.com) issue and
supply a unit test case for this? Module is jboss cache and you can assign it
to me.
|
| I have tried to reproduce it using replicated/SyncTxUnitTestCase by
assigning the islolation level to NONE. But only the ca
One more problem found. I have 2 nodes in replicated cluster with following
descriptor (the same for both nodes):
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| jboss:service=Naming
| jboss:service=Transact
"[EMAIL PROTECTED]" wrote : can you verify this is also broken in 1.2.1 (CVS
head) ?
Just updated from jboss-head and it's still there.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863051#3863051
Reply to the post :
http://www.jboss.org/index.html?module=
There's a bug in 1.2 release. Reproduced on cache running in replicated mode
when IsolationLevel=NONE
cache.put() causes exception:
| Caused by: java.lang.RuntimeException: getLockStrategy: LockStrategy
selection not recognized. selection: NONE
| at
org.jboss.cache.lock.LockStra
I have a deployed webapp which depends on some mbean (having depends clause in
jboss-web.xml).
When mbean is being redeployed it causes redeploying this webapp which finishes with
NPE in WebModule.java
This bug reproduced in both jboss 4.0.0 and 3.2.6
Simple test case:
Create sample service in
When transaction is being rolled back there's a NPE in afterCompletion:
| [OrderedSynchronizationHandler] failed calling afterCompletion() on
org.jboss.cache.interceptors.Repli
| [EMAIL PROTECTED]
| java.lang.NullPointerException
| at
org.jboss.cache.interceptors.ReplicationInter
Wow! in the latest jboss-head it's gone. Great job, thanks.
Looking forward for 1.1 release.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846419#3846419
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3846419
Ben, just to assure it's not an artificial case: the bug appears in my real
application where cache is to cache stock charts which are produced in relatively long
time but frequently requested from web (8-digit requests daily).
I reproduce this bug just running some 10 threads in JMeter making w
Ben,
Here's a test unit which reproduces this bug in 100% run. default
local-eviction-service.xml is taken with no changes. _defatlt_ region is used with
maxModes=5000. Here it is:
| public void test2() throws Exception {
| cache = new TreeCache();
| PropertyConfigurat
Uwen, Ben,
Of course I do not consider this particular out of memory exception as a bug.
The thing is OutOfMem CAUSED by exception which is this thread's topic.
In my last post - take a look - first this exception appeared, it repeated with each
eviction cycle effectively stopping eviction.
Th
Ben,
Unfortunately, it's still there. I updated from cvs-head and run my testcase which I
used in the beginning of this thread. It took an hour before this exception appeared.
Seems somehow it depend on system load..
Uve, Could you also try to reproduce this bug to assure Ben it's a real thing
I've just put latest jboss-cache.jar into jboss and run my application testunit. It's
about the same I used above. It puts as much as possible my cached objects to cache.
Shortly after start I noticed that number of cached object keep rising far above limit
(1). I stopped my testcase.
Then,
Ben,
Now it's working much better, it takes some time to get this error. But unfortunately,
it's still there.
Seems it heavily depends on system load. It I put Thread.sleep(10) in putting thread
it never happens.
| configure(): attribute size: 25
| setClusterConfig(): setting cluster prope
Seems that exactly this error already been posted on this forum
http://jboss.org/index.html?module=bb&op=viewtopic&t=52457
as far as I see it's still exists.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3845885#3845885
Reply to the post :
http://www.jboss
Under (relatively) heavy load LRUAlgorithm for some reason tries to remove the same
node twice. Result is java.lang.RuntimeException: LRUAlgorithm.evict(): null node map
entry for fqn: /test1/node835264.
Test case. local-eviction-service.xml is used. Default region - 5000 nodes max. LRU
polic
19 matches
Mail list logo
