Good! Release 1.1 is coming out in couple days. Again, thanks for the great help from
you guys!
-Ben
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846487#3846487
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3846487
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
Uwe,
That is good news, isn't it?
Octopus, can you download the latest jboss-head and test it again? I have minor
changes checked in yesterday. Make sure Region.java now has a warning message for
reaching over the threshold value.
If there is still an issue, I'd like to track it down. I ran yo
Octopus, Ben,
using the most current sources from jboss-head and the posted testcase,
I can't find the described issue. I did a lot of testing,
but I am afraid - I cant help...
-Uwe
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3846348#3846348
Reply to the
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
Guys,
I don't think it is a bug. I can also re-produce the OOM error myself here as well.
The key is the load is simply not realistic if we have multiple threads that are
generating put and get all the time and thus exhibiting 100% CPU.
A more realistic use case will requires a random sleep in
Guys,
I don't think it is a bug. I can also re-produce the OOM error myself here as well.
The key is the load is simply not realistic if we have multiple threads that are
generating put and get all the time and thus exhibiting 100% CPU.
A more realistic use case will requires a random sleep in
Hi,
I can easily reproduce the java.lang.OutOfMemoryError with the testcase,
but I am not sure - if this is really a bug.
Could it be possible, that simply the parameters in local-eviction-service.xml are not
optimal for the use case and the environment?
-uwe
View the original post :
http://w
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
Uwe,
You are right! I thought I have fixed this in release1.02. But I couldn't find any
trace in cvs log! So I am embarassed to say that I must have let it slip through. :-)
Anyway, I have just checked in to the code into jboss-head. Please grab it and re-try
again.
Thanks,
-Ben
View the ori
Can you guys try it one more time by getting the latest jboss-head? It is actually not
a serious error, per se. Here is why.
What happened was in TreeCache, it will do another nodeModified event notification
after the parent (leaf node has no problem) node is evicted. So you see, it will loop
b
I encounter the same problem, the exception for the no-existing node is raised again
and again.
Maybe the problem is again related to the Bug: [ 1013153 ] infinite loop in
LRUAlgorithm.prune
There has been a discussion about this, the related bug has been closed, but I see the
problematic code
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
Hi,
Since I have just refactored the eviction policy last week, I have tried your test
case on the latest code on jboss-head. I don't see any error right now. So can you try
it yourself to make sure the problem is resolved?
I will incorporate your test case.
Thanks,
-Ben
View the original po
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
18 matches
Mail list logo
