Bug 745912 (EDG-19)

A few more notes:

The test fails on this line: Assert.assertEquals(null, cache.get("k2"));

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

Link: Added: This issue is related to ISPN-1285

Martin, thanks for the report. As noted in ISPN-1285, it's currently not possible to fix this due to limitations on the 1st version of the protocol. There is however a valid workaround as noted in the JIRA, so I'm closing this as deferred.

Release Notes Docs Status: Added: Not Yet Documented
Release Notes Text: Added: Due to limitations on the first version of the Hot Rod protocol, it's not possible for clients to rely on default lifespan and maxIdle values set on the server. This is because the protocol does not support a way to tell the server that no expiration lifespan and/or maxIdle were provided and that default values should be used. This will be resolved in a future revision of the protocol. In the mean time, the workaround is to explicitly provide the desired expiry lifespan/maxIdle values in each remote cache operation.

Link: Added: This issue relates to JBPAPP-6957

This issue is there also for REST access method. A user can use a REST call not specifying timeToLive which means these entries will remain in the cache forever. (the new test can be found at the same URL as the test for HotRod). So I think the Release Notes text should mention it as well. This issue doesn't appear when using memcached protocol since user has to always specify expiration. 

Martin, as discussed earlier, I needed to run some tests to verify this. The results can be found in ISPN-1285, but in summary:
- Memcached suffers same issue as Hot Rod and so requires each operation to send lifespan/maxIdle.
- The REST endpoint *is not* affected by this, see details in ISPN-1285 to understand how the server behaves. 

So when the REST endpoint is not affected by this then the web application (REST - available under /datagrid) deployed in EDG must behave wrong. I wrote a test: https://svn.devel.redhat.com/repos/jboss-qa/edg/edg-functional-tests/trunk/expiration/src/test/java/org/jboss/test/datagrid/expiration/RESTExpirationTest.java which fails at line 85: head(fullPathKeyServer1, HttpServletResponse.SC_NOT_FOUND); - this means that we expect the entry *not to* be there but it is. I did not specify neither maxIdleTimeSeconds nor timeToLiveSeconds and the entry was found in the cache even after it should have expired (according to settings in standalone.xml file). 

Oops, the REST endpoint and the application under /datagrid context path is the same :)....but then I don't get why the test fails, strange.

Release Notes Text: Removed: Due to limitations on the first version of the Hot Rod protocol, it's not possible for clients to rely on default lifespan and maxIdle values set on the server. This is because the protocol does not support a way to tell the server that no expiration lifespan and/or maxIdle were provided and that default values should be used. This will be resolved in a future revision of the protocol. In the mean time, the workaround is to explicitly provide the desired expiry lifespan/maxIdle values in each remote cache operation. Added: Due to limitations on the first version of the Hot Rod protocol, it's not possible for clients to rely on default lifespan and maxIdle values set on the server. This is because the protocol does not support a way to tell the server that no expiration lifespan and/or maxIdle were provided and that default values should be used. This will be resolved in a future revision of the protocol. In the mean time, the workaround is to explicitly provide the desired expiry lifespan/maxIdle values in each remote cache operation.

The same problem is present in the Memcached server as well because the protocol offers no possibility of not sending an exptime (equivalent to lifespan). So, Memcached servers cannot rely on the default expiry values configured in XML/programmatically. The workaround for Memcached servers is the same as for Hot Rod servers, which is sending explicit exptime values.

The REST server works slightly different, and with a combination of timeToLiveSeconds and maxIdleTimeSeconds values, it can rely on default configured expiry lifespan and maxIdle values. For more information, please check the RESTful interface documentation in https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+via+RESTful+interface.

Release Notes Docs Status: Removed: Not Yet Documented 
Release Notes Text: Removed: Due to limitations on the first version of the Hot Rod protocol, it's not possible for clients to rely on default lifespan and maxIdle values set on the server. This is because the protocol does not support a way to tell the server that no expiration lifespan and/or maxIdle were provided and that default values should be used. This will be resolved in a future revision of the protocol. In the mean time, the workaround is to explicitly provide the desired expiry lifespan/maxIdle values in each remote cache operation.

The same problem is present in the Memcached server as well because the protocol offers no possibility of not sending an exptime (equivalent to lifespan). So, Memcached servers cannot rely on the default expiry values configured in XML/programmatically. The workaround for Memcached servers is the same as for Hot Rod servers, which is sending explicit exptime values.

The REST server works slightly different, and with a combination of timeToLiveSeconds and maxIdleTimeSeconds values, it can rely on default configured expiry lifespan and maxIdle values. For more information, please check the RESTful interface documentation in https://docs.jboss.org/author/display/ISPN/Accessing+data+in+Infinispan+via+RESTful+interface. 
Docs QE Status: Removed: NEW 

Is this marked for Release Notes? If so, it does not need to be assigned to the Documentation component, the requires_release_notes? flag is sufficient.