| Summary: | cas unique value should be treated as 64bit unsigned integer | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Data Grid 5 | Reporter: | Michal Linhard <mlinhard> |
| Component: | Infinispan | Assignee: | Default User <jbpapp-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | unspecified | CC: | nobody |
| Target Milestone: | --- | ||
| Target Release: | EAP 5.1.0 EDG TP | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | http://jira.jboss.org/jira/browse/EDG-76 | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-11-25 18:10:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Michal Linhard
2010-11-22 14:47:05 UTC
Hmmmm, the document says nothing about cas unique being an unsigned integer. All it says is: "<cas unique> is a unique 64-bit value of an existing entry." "<cas unique> is a unique 64-bit integer" There's no reference o unsigned actually, so a simple Java long should do. Remember as well that the cas unique is not necessarily a counter. It can be implemented as such but the aim is a different one. It tries to identify modifications in a unique way. In fact, we've implemented it so that part of it is a counter but the other might not, particularly if running in a cluster. Yep you're right there's no mention of "unsigned" I just got carried away, because the original implementation allows these values (0 .. 18446744073709551615) which means that they are parsing it as unsigned integer. The way casid is used (for optimistic locking) is: 1. set 2. gets, store returned casid 3. cas, pass casid as parameter so in cas command the server never gets a wrong value, because he generated it himself. problem can be on client side in step2 if client only expects unsigned 64bit integer. can we generate negative casid ? the way it is implemented now: <view id (2 bytes)><rank (2 bytes)><version counter (4 bytes)> can view id sometimes have 1 as MSB ? if this never happens we're safe... if yes we could maybe switch view_id and rank order because rank's basically number of nodes in view which hardly even exceeds 1000. I agree that rank reaching 1000 is less unlikely than view ID, which are the number of view changes. It's quite an edge case tbh, but as you said, I'd swap around the rank and view ids to protect against this just in case. I need to verify how easy is it to keep this value within the unsigned ranges. I don't want add too much complexity here cos it's a part of the code that is used a lot. Each modification generates a new cas/version, so I'd rather keep it efficient than dealing with negative values here. Link: Added: This issue depends ISPN-802 I'm rejecting this since the Memcached spec is not specific enough in terms of whether the cas/version number should be unsigned or not. I'm rejecting this since the Memcached spec is not specific enough in terms of whether the cas/version number should be unsigned or not. |