[ https://issues.jboss.org/browse/ISPN-858?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-858: ---------------------------------- Summary: MIMECacheEntry requires a version (was: Calculated ETag not accurate enough) Description: ETag calculation requires MIMECacheEntry to carry a version similar to HotRod/Memcached in order to avoid collisions with closely followed updates. (was: MIMECacheEntry's lastModified attribute only has second accuracy, so you updates that are performed in same second where content type and length stays the same, a collision occurs - ETag stays the same although the values are not identical.) ISPN-713 has made this issue more easily reproducable, but the underlying reason is that as per strong ETag rules in, http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3, after each modification the ETag must be different, so relying on time, content type and data length is not good enough. -- 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-858?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-858: --------------------------------------- Yeah, reached the same conclusion in JBPAPP-5715. I was thinking of using along the lines of the version use in HotRod/Memcached, which integrates cluster node information if available, and an counter. Why would relying on a counter lead to unnecessary cache invalidation? I'd imagine that the counter would get updated whenever the new MIMECacheEntry gets updated which happens on a put() call I can only think of too much invalidation happening if the counter was incremented in spite of the contents not changing. -- 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-858?page=com.atlassian.jira.plugin.s... ] Manik Surtani commented on ISPN-858: ------------------------------------ Well, if the contents change to something that is equal then you have an unnecessary counter increment. E.g., MIMECacheEntry.setValue("a"); // version = 1 MIMECacheEntry.setValue("a"); // version = 2 MIMECacheEntry.setValue("a"); // version = 3 You could just increment the version if the value changes, but that means doing an equals() on a byte[] which is expensive. I wonder if calculating a MurmurHash on the contents is faster/cheaper. :-) -- 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-858?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño commented on ISPN-858: --------------------------------------- https://github.com/infinispan/infinispan/pull/116 -- 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-858?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño resolved ISPN-858. ----------------------------------- Resolution: Done -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira