For those who were wondering, I’ve not forgotten about this thread, but in the last few days I saw something that made my reconsider this...
To be more precise, I saw some code of a user that was trying to keep a counter using Hot Rod. When inspected closely, Will and I realised that the user code had a very subtle bug that meant that ISPN-4972 could happen when the counter was first updated. I’ve just tried the code in place of the `incrementCounter` method in the counter stress test we have in the testsuite [1] and the test fails as expected. You end up with incorrect counter number, e.g. should count to 4000 but ends up with 4001. This is quite dangerous and spotting these kind of issues in the user code can take up a lot of time, so I’m rethinking again what to do about this. I’m not sure yet. I’ll reply back. Cheers, [1] https://github.com/infinispan/infinispan/blob/master/client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ReplaceWithVersionConcurrencyTest.java On 13 Nov 2014, at 14:08, Radim Vansa <rva...@redhat.com> wrote: > I agree with Galder, fixing it is not worth the cost. > > Actually, there are often bugs that I'd call rather 'quirks', not > honoring the ConcurrentMap contract (recently we have discussed with Dan > [1] and [2]) which are quite complex to fix. Another one that's > considered not a bug is that a read does not have transactional semantics. > Galder, where will you document that? I think that special page in > documentation should accumulate such cases, linked to JIRAs for case > that eventually we'll resolve them (with that glorious MVCC). And of > course, link from javadoc to this document (though I am not sure whether > we can correctly keep that in sync with latest release. Could we have a > redirection from http://infinispan.org/docs/latest to > http://infinispan.org/docs/7.0.x/ ? > > Radim > > [1] https://issues.jboss.org/browse/ISPN-3918 > [2] https://issues.jboss.org/browse/ISPN-4286 > > On 11/13/2014 01:51 PM, Galder Zamarreño wrote: >> Hi all, >> >> Re: https://issues.jboss.org/browse/ISPN-4972 >> >> Embedded cache provides atomicity of a replace() call passing in the >> previous value. This limitation might be lifted when we adopt Java 8 and we >> can pass in a lambda or similar, which can be executed right when the value >> is compared now, and if it returns true it’s applied. The lambda could >> compare both value and metadata for example. >> >> Anyway, given the current status, I’m considering whether it’s worth fixing >> this particular issue. Fixing the issue would require adding some kind of >> locking in the Hot Rod server so that the version retrieval, comparison and >> replace call, can all happen atomically. >> >> This is not ideal, and on top of that, as Radim said, the chances of this >> happening in real life are limited, or more precisely it’s effects are >> minimal. In other words, if two concurrent threads call replace with the >> same value, the end result is that the new value would be stored, but as a >> result of the code, both replaces would return true which is not strictly >> right. >> >> I’d rather document this than add unnecessary locking in the Hot Rod server >> where it deals with the versioned replace call. >> >> Thoughts? >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <rva...@redhat.com> > JBoss DataGrid QA > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
