-
1. Re: exception in LRUAlgorithm
ben.wang Mar 31, 2005 8:43 PM (in response to kkalmbach)Please contribute a unit testing to re-produce this prolem. I don't think is ignorable error.
Thanks a lot,
-Ben -
2. Re: exception in LRUAlgorithm
kkalmbach Apr 4, 2005 5:38 PM (in response to kkalmbach)After much searching I think I found my problem.
Does this make sense to you..
I do not specify a isolation level in my service.xml, so (I think) I use the "LockStategyNone".
When I have 2 threads doing a repeated add/removes on the same node. One does not wait on the other, and the adds and deletes are inter-mingled. So in the nodeEvent queue, I get an add/add/delete/delete. Then when the eviction alogrithm starts to process the queue, it processes an add, then another add (which does not do anything, because it is already in the map), then a delete and then the second delete fails.
a few questions..
1) Is this a reasonable explanation of what is going on?
2) Does the default LockStragety make sense, should it ever be used? should the default change?
3) Does the eviction policy need changing to accomodate this (allow multiple entries in the map, or ignore the error, or ??)
I can send trace level logs if you want, but they are too large to post here.
Thanks
-Kevin -
3. Re: exception in LRUAlgorithm
ben.wang Apr 4, 2005 6:02 PM (in response to kkalmbach)Kevin,
The default lock strategy should be REPEATABLE_READ if you don't specify any. So that still does not explain why you are getting to delete it twice.
There is a scenario can happen though. When eviction policy is trying to evict a node, another thread swoop in to delete the node first. As a result, node not found can result. Since our eviction policy is not syncrhonous, we should allow this scenario to go through without error.
-Ben -
4. Re: exception in LRUAlgorithm
kkalmbach Apr 4, 2005 9:36 PM (in response to kkalmbach)Looking at the logs, I do not think this is related to the eviction policy running.
I definatly see one thread getting a write lock, then another thread getting a write lock (for the same node) before the first one is finished. Here is what I see happening....
T1 is Thread1, T2 is Thread2. (Please excuse the ascii sequence diagram)T1 T2 Cache NodeEventq put ------------------> add nodeEvent---------------------------------> add remove----------------> remove put ---------> add nodeEvent------------------------> add nodeEvent---------------------------------> remove remove-------> remove nodeEvent------------------------> remove
Then when the eviction Timer wakes up and tries to run through the nodeEventQueue, it hits 2 adds then 2 deletes.