[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Manik Surtani reassigned ISPN-1285: ----------------------------------- Assignee: Galder Zamarreño (was: Manik Surtani) Galder, could you pls look into this? Odd, since we have unit tests for this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Work on ISPN-1285 started by Galder Zamarreño. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1285: ----------------------------------- Summary: Cache entries stored via Hot Rod client with default expiry remain in cache (was: Expired cache entries remains in the cache) Description: 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. (was: Default values for expiration specified via Infinispan configuration file (tag <expiration lifespan="2000" maxIdle="1000" />) do not influence real lifespan of cache entries. A test that proves this can be found at https://svn.devel.redhat.com/repos/jboss-qa/edg/infinispan-functional-tes.... To run it, one has to set ISPN_HOME property pointing to standalone Infinispan (e.g. /tmp/infinispan-5.0.0.CR8) and run "mvn clean verify". Configuration files (infinispan-config-repl.xml) can be found in the project under src/test/resources and are used automatically for the test. The test is using 2 standalone Infinispan instances with replicated cache and configured file cache stores. Expiration should remove a cache entry from all locations (all cache in the cluster, all cache stores). The test fails on this line: Assert.assertEquals(null, cache.get("k3")); To run the test it is also needed to checkout the following projects and run "mvn clean install" on them: https://github.com/arquillian/arquillian-core https://github.com/infinispan/infinispan-arquillian-container The test will use hostnames test1 and test2, so these should be bound to virtual interfaces.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1285: ---------------------------------------- This is a bit tricky actually. One way to get around it would be to assign a new flag that the Hot Rod client can pass to let the server know that the 0/0 lifespan/maxIdle parameters are 0 because the client didn't pass any, and so the server could use the default expiry/lifespan values. However, creating this new flag would mean changing the protocol. Checking more options... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-1285: ----------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/484 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-1285: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] 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... 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... 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). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Martin Gencur edited comment on ISPN-1285 at 8/3/11 12:32 PM: -------------------------------------------------------------- I see, so when I want the default values set inside Infinispan xml config file to take effect, I have to send headers ToLiveSeconds and maxIdleTimeSeconds set to 0, right? But this is not intuitive. I would presume that when I don't send any http headers the default values will be used (those set in xml config file) because in the xml config file we override defaults => we set new default, IMO. was (Author: mgencur): I see, so when I want the default values set inside Infinispan xml config file to take effect, I have to send headers ToLiveSeconds and maxIdleTimeSeconds set to 0, right? But this is not intuitive. I would presume that when I don't send any http headers the default values will be used (those set in xml config file). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-1285: ---------------------------------------- I agree that this is not intuitive (it's not even symmetric!), and it's like this cos it was not designed with this use case in mind. What I explained above is what the code looks like today, and it's too late to change it right now since it's part of the REST protocol. In the same way that we have a JIRA for a second version of the Hot Rod protocol, we need a JIRA for the 2nd version of the REST protocol where this kind of stuff can be tightened. It'd need some investigation to see how to accomodate different REST protocol versions. Exactly, the documentation does not say anything cos no one has looked into this until now and hence I had not yet had time to change the docu to show this :). That's precisely what I'm planning to do once I've committed a unit test that verifies the current behaviour. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-1285?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-1285: ------------------------------------- Perfect! Thank you Galder:) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira