Hide Forgot
project_key: EDG affects infinispan 4.2.0.FINAL due to a bug in my testsuite, I discovered this only now, even though I wrote a testcases for ETags sooner: calculation of etag depends only on content type, last modified time and data length: def calcETAG(entry: MIMECacheEntry) = new EntityTag(entry.contentType + entry.lastModified + entry.data.length) which means that when updates are performed in same second and content type and length stays the same, the collision occurs - ETag stays the same although the values are not identical.
TestCase: testETagChanges() in https://anonsvn.jboss.org/repos/jbossas/branches/JBPAPP_5_1_datagrid/testsuite/src/main/org/jboss/test/cluster/datagrid/test/RESTClientTestCase.java
Link: Added: This issue depends ISPN-858
The modifications made as part of this JIRA resulted in the loss of precision. I'm going back to that JIRA to try to understand what the original issue was. Michal, do you have the code for the test case of that original JIRA?
Link: Added: This issue is related to JBPAPP-5262
Right, I think I've found the original test, it's testIfUnmodifiedSince in that same file.
the change in MIMECacheEntry that was part of the JBPAPP-5262: public MIMECacheEntry(String contentType, byte[] data) { this.contentType = contentType; this.data = data; +++ lastModified = System.currentTimeMillis() / 1000 * 1000; --- lastModified = System.currentTimeMillis(); } only made this more probable (the updates have to be more than a second apart to not collide) without JBPAPP-5262 it would be one millisecond, but wouldn't that be still a problem ?
Indeed it'd be a problem cos it'd be considered a weak validator as per http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3 which indicates how ETags are compared. It appears that a version ala Memcached/HotRod is needed in order to identify individual changes, regardless of the time difference.