[jbosscache-issues] [JBoss JIRA] Commented: (JBCACHE-1582) ExpirationAlgorithm doesn't evict nodes that have been created in a long Tx

[Galder Zamarreno (JIRA)]

    [ https://jira.jboss.org/browse/JBCACHE-1582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12533472#action_12533472 ] 

Galder Zamarreno commented on JBCACHE-1582:
-------------------------------------------

At first glance, there appear to be two issues:

- On one side, the LRU test fails cos there's a timeout exception reported when trying to evict a locked node. However, such timeout does not lead to the eviction being put back in the recycle queue, so as a result the eviction is lost. DefaultEvictionActionPolicy shows this:

   public boolean evict(Fqn fqn)
   {
      try
      {
         if (log.isTraceEnabled()) log.trace("Evicting Fqn " + fqn);
         cache.evict(fqn);
         return true;
      }
      catch (Exception e)
      {
         if (log.isDebugEnabled()) log.debug("Unable to evict " + fqn, e);
         return false;
      }
   }

But BaseEvictionAlgorithm.evictCacheNode does nothing with this result:

   protected boolean evictCacheNode(Fqn fqn)
   {
      if (trace) log.trace("Attempting to evict cache node with fqn of " + fqn);

      try
      {
         evictionActionPolicy.evict(fqn);
      }
      catch (TimeoutException e)
      {
         log.warn("Eviction of " + fqn + " timed out, retrying later");
         log.debug(e, e);
         return false;
      }
      catch (Exception e)
      {
         log.error("Eviction of " + fqn + " failed", e);
         return false;
      }

      if (trace)
      {
         log.trace("Eviction of cache node with fqn of " + fqn + " successful");
      }

    }

The failure is swallowed and hence LRUAlgorithm.evict does not recycle it.

- On the other side, the expiration algorithm issue is the one indicated in the initial comment.

The first issue could be solved by making recycle queue worked as expected. 

An option for the second issue would be the following: If there's a transaction going, do not add events for CRUD methods until the prepare phase. This would allow eviction to work on an existing node as long as the commit phase happened before the next eviction run, but this is not a guarantee though. More thinking is needed to solve this.

> ExpirationAlgorithm doesn't evict nodes that have been created in a long Tx 
> ----------------------------------------------------------------------------
>
>                 Key: JBCACHE-1582
>                 URL: https://jira.jboss.org/browse/JBCACHE-1582
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Eviction
>    Affects Versions: 3.2.5.GA
>            Reporter: Nicolas Filotto
>            Assignee: Manik Surtani
>         Attachments: TestEvictionAlgorithms.java, TestExpirationAlgorithm.java, TestExpirationAlgorithm.java, TestExpirationAlgorithm.java
>
>
> I noticed that I had a memory leak in my application when I use the ExpirationAlgorithm (maybe this bug happens with other algorithms) due to some nodes that were never evicted. After a deeper investigation, I noticed that no EvictionEntry was created for those nodes since the method getExpiration returns null (which also means that cache.peek(fqn, false) returns null). I finally found the problem, that is because if the Expiration Thread wakes up before that the related Tx is committed, it doesn't find the node into the cache so it considers it as removed but in fact it is just because the Tx has not yet been committed. This has for consequence that the node will never be evicted and thus create a memory leak.
> Please find the related unit test as attached file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira