[infinispan-issues] [JBoss JIRA] Issue Comment Edited: (ISPN-1285) Cache entries stored via Hot Rod client with default expiry remain in cache

[Galder Zamarreño (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618544#comment-12618544 ] 

Galder Zamarreño edited comment on ISPN-1285 at 8/3/11 12:01 PM:
-----------------------------------------------------------------

*NOTE*: The server does not currently behave symmetrically when only one of the two parameters (timeToLiveSeconds or maxIdleTimeSeconds) is 0. I think it's a bit late to change it but it's the way it works.

Martin has asked whether this issue affects to Memcached and REST endpoints too.

* For Memcached, the issue is there as well because the protocol only differentiates between two values (0 or negative, and positive), so you can't really know whether 0 or negative was because the client did not provide the lifespan, or because it explicitly set it to 0.
* However, the REST endpoint does not have this issue because the server server differentiates between 3 values (-1, 0, positive) as opposed to the other endpoints that differentiate only between two (negative, positive). So, how does the REST server behave? You can see it in https://github.com/infinispan/infinispan/blob/master/server/rest/src/main/scala/org/infinispan/rest/Server.scala but basically, this is what happens:
** If both timeToLiveSeconds and maxIdleTimeSeconds are 0, default configured expiry values (lifespan and maxIdle) will be used:
{code}case (0, 0, false) => cache.put(key, obj){code}
** If only maxIdleTimeSeconds is 0, it uses the lifespan value passed as parameter (or -1 if not present which means, live forever), and default maxIdle configured:
{code}case (x, 0, false) => cache.put(key, obj, ttl, TimeUnit.SECONDS){code} 
** If only timeToLiveSeconds is 0, it uses 0 as lifespan (it will expire immediately) and maxIdle is set whatever came as parameter (or -1 if not present which means, live forever):
{code}case (x, y, false) => cache.put(key, obj, ttl, TimeUnit.SECONDS, idleTime, TimeUnit.SECONDS){code}


      was (Author: galder.zamarreno):
    Martin has asked whether this issue affects to Memcached and REST endpoints too.

* For Memcached, the issue is there as well because the protocol only differentiates between two values (0 or negative, and positive), so you can't really know whether 0 or negative was because the client did not provide the lifespan, or because it explicitly set it to 0.
* However, the REST endpoint does not have this issue because the server server differentiates between 3 values (-1, 0, positive) as opposed to the other endpoints that differentiate only between two (negative, positive). So, how does the REST server behave? You can see it in https://github.com/infinispan/infinispan/blob/master/server/rest/src/main/scala/org/infinispan/rest/Server.scala but basically, this is what happens:
** If both timeToLiveSeconds and maxIdleTimeSeconds are 0, default configured expiry values (lifespan and maxIdle) will be used.
** If only timeToLiveSeconds is 0, it uses 0 as lifespan (it will expire immediately) and maxIdle is set to -1 (live forever). 
** If only maxIdleTimeSeconds is 0, it uses 0 as maxIdle (it will expire immediately) and lifespan is set to -1 (live forever). 
  
> Cache entries stored via Hot Rod client with default expiry remain in cache
> ---------------------------------------------------------------------------
>
>                 Key: ISPN-1285
>                 URL: https://issues.jboss.org/browse/ISPN-1285
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 5.0.0.CR8
>            Reporter: Martin Gencur
>            Assignee: Galder Zamarreño
>             Fix For: 5.0.0.FINAL
>
>
> Default values for expiration specified via Infinispan configuration file (tag <expiration lifespan="2000" maxIdle="1000" />) do not influence real lifespan of cache entries stored via the Hot Rod client.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira