From: <be...@jb...> - 2006-02-28 07:39:49
|
I think these are just error messages, because the eviction thread added the nodes to the queue and later - when trying to remove those - they were already removed, so these are no-ops. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3926716#3926716 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3926716 |
From: drosenbaum <do-...@jb...> - 2006-02-28 15:29:22
|
Thanks Bela for responding. But is this the correct way to clear the cache? Or is there some other proper method or API that I missed (and prefereably would not result in these error messages)? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3926825#3926825 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3926825 |
From: <be...@jb...> - 2006-02-28 15:46:20
|
No, you're doing the right thing. The question for the eviction guys is whether we retry an eviction if we cannot find the element in the cache, or whether we remove the eviction element from the queue... I hope/think we do the latter View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3926830#3926830 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3926830 |
From: drosenbaum <do-...@jb...> - 2006-03-01 19:08:37
|
Could one of the "eviction guys" please comment on this issue? Or should I file a bug report? Thanks once again, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927217#3927217 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927217 |
From: <ben...@jb...> - 2006-03-02 04:37:30
|
Daniel, I am the cache guy. :-) I assume you can reproduce this everytime? If so, can you open up a Jira and attach your unit test case? Btw, what is the JBossCache release that you used? Yes, the remove method is supposed to remove it from the eviction queue so it won't get evicted again. The EvictTimerTask error is an internal exception thrown from the eviction policy. It is probably something to do with your remove("/"). I tried to re-produce it but I can't. Thanks, -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927340#3927340 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927340 |
From: drosenbaum <do-...@jb...> - 2006-03-02 14:50:36
|
Thanks Ben for responding. Unfortunatly it does not happen every time. All I know is that I have had an application running with JBossCache for about 6 months now and I get messages such as this about once a week or 2, sometimes more often and sometimes less. I have a process that runs every morning at 4 am and clears the cache, as I would like to start fresh each day with new data. There are times we need to clear the cache manually as well, such as if we modify the underlying data in the database and need our web app to use the new data. This does not happen often but there are times when it is necessary. I suspect (though I have no way to prove) that these messages appear when elements are put in the queue for eviction, but before the thread gets around to actually evicting the elements the remove("/") is called, so the elements are no longer in the cache when the EvictTimerTask tries to remove it. Does this make any sense? I have no idea how to write a unit test for this though and is probably difficult to reproduce. I am now using version 1.2.4SP1 the last few weeks and 1.2.2 previously, and I am seeing these log messages in both versions. Thank you, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927461#3927461 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927461 |
From: drosenbaum <do-...@jb...> - 2006-03-02 14:54:20
|
One other thought, you say that "the remove method is supposed to remove it from the eviction queue". When I call remove("/"), are all child elements of that node also being removed from the eviction queue? And the children's children at all levels of the subtree? Maybe what is happening is that only the root element is being removed from the eviction queue but not the descendants? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927462#3927462 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927462 |
From: <ben...@jb...> - 2006-03-03 05:45:25
|
No, since remove("/") is recursive, so it should be removing each sub-node as well. Like I said, I have a temporary test case trying to re-produce it but couldn't. Is there any complicated test that you are doing there? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3927664#3927664 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3927664 |
From: drosenbaum <do-...@jb...> - 2006-03-06 23:14:29
|
After working for a while I was able to come up with a JUnit test case that reproduces this. The code is below. I started with the org.jboss.cache.eviction.LRUPolicyTest class and added the following test: public void testForEvictionInternalError() { | try { | String rootStr = "/test/testdata"; | | for (int i = 0; i < 10; i++) { | String str = rootStr + i; | Fqn fqn = Fqn.fromString(str); | try { | cache_.put(fqn, str, str); | } catch (Exception e) { | fail("Failed to insert data" + e); | e.printStackTrace(); | } | } | | // wait for an eviction | _sleep(2 * wakeupIntervalMillis_ + 1000); | | String val = (String) cache_.get(rootStr + "3", rootStr + "3"); | assertNull("DataNode should be empty ", val); | | // reinsert the elements | for (int i = 0; i < 10; i++) { | String str = rootStr + i; | Fqn fqn = Fqn.fromString(str); | try { | cache_.put(fqn, str, str); | } catch (Exception e) { | fail("Failed to insert data" + e); | e.printStackTrace(); | } | } | | // clear the root | Fqn root = cache_.get("/").getFqn(); | cache_.remove(root); | | // wait for an eviction | _sleep(2 * wakeupIntervalMillis_ + 1000); | | val = (String) cache_.get(rootStr + "3", rootStr + "3"); | assertNull("DataNode should be empty ", val); | | } catch (Exception e) { | e.printStackTrace(); | fail("Failed to get" + e); | } | } on almost all the executions I end up having the following log statement somewhere: org.jboss.cache.eviction.EvictionException: internal error. Can't find fqn in nodeMap. fqn: /test | at org.jboss.cache.eviction.LRUAlgorithm.removeFromQueue(LRUAlgorithm.java:215) | at org.jboss.cache.eviction.LRUAlgorithm.processRemovedNodes(LRUAlgorithm.java:107) | at org.jboss.cache.eviction.LRUAlgorithm.processQueues(LRUAlgorithm.java:80) | at org.jboss.cache.eviction.LRUAlgorithm.process(LRUAlgorithm.java:53) | at org.jboss.cache.eviction.EvictionTimerTask.run(EvictionTimerTask.java:37) | at java.util.TimerThread.mainLoop(Timer.java:432) | at java.util.TimerThread.run(Timer.java:382) I did not figure out a way to ALWAYS get this message but it appears in the majority of runs. Note that you need to actually look at the log to see it, the test itself always passes, so it is not sufficient to wait for a test to fail. What I think is now happening is when you insert a node, wait until it gets evicted by the system, and then reinsert the same node and call cache.remove("/"), the log message appears after that. (But I am not sure of all this) Please let me know if this test produces this log warning for you as well. Thank you, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928317#3928317 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928317 |
From: <ben...@jb...> - 2006-03-07 10:22:25
|
OK, let me see if I can reproduce it. Will post my finding here. -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928418#3928418 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928418 |
From: <ben...@jb...> - 2006-03-08 08:42:15
|
Daniel, OK, I have created this Jira: http://jira.jboss.com/jira/browse/JBCACHE-494 that explains the cause and fix as well. Since IMO this is a corner case, we won't provide an official patch. However, you can build jboss-cache.jar yourself: cvs co -r Branch_JBossCache_1_2_4_SP2 JBossCache Do buiild jar Please wait for one day for the cvs to propagate. Thanks for your help, -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928684#3928684 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928684 |
From: <ben...@jb...> - 2006-03-08 09:00:00
|
I just attached jboss-cache for the unofficial 1.2.4SP2 patch in the Jira, please check it out. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928689#3928689 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928689 |
From: drosenbaum <do-...@jb...> - 2006-03-08 17:12:47
|
Thank you Ben for resolving this. Cheers, Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928803#3928803 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928803 |
From: drosenbaum <do-...@jb...> - 2006-03-08 19:02:19
|
One comment though, could it be made into a debug or info message rather than a warning? I have my logs configured to show warnings and would rather not see such log messages at all, since it is not really a problem. I am not sure why it deserves a level of warn. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928828#3928828 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928828 |
From: <ben...@jb...> - 2006-03-09 04:11:47
|
hmmn... true enough. I had thought about it actually but was undecided. I will turn it into INFO then. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3928938#3928938 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3928938 |
From: drosenbaum <do-...@jb...> - 2006-03-15 15:48:23
|
Bela, I would like to follow up. I notice in FishEye that you changed the log statement in BaseEvictionAlgorithm.java from warn to debug but as far as I can tell you did not change it in LRUAlgorithm.java. Did you perhaps forget about it? I just want to make sure it wasn't missed, as this is an easy thing to forget or overlook. Thank you once again for all your help. Daniel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930391#3930391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3930391 |
From: <ben...@jb...> - 2006-03-16 09:10:53
|
Daniel, that was that did it. :-) I ahve done it in two branches. In Head, it has been refactored into BaseEvictionAlgorithm now. So no need to change it there. -Ben View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3930589#3930589 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3930589 |