CAS doesn't work with Couchbase 2.0 #8

Closed
etodd opened this Issue Aug 9, 2012 · 10 comments

Comments

Projects
None yet
3 participants

etodd commented Aug 9, 2012

Ubuntu 12.04 64-bit. We were using ultramemcache quite happily with Couchbase 1.8.1. I seem to recall 1.8.1 generating relatively short CAS values (maybe 5 digits). 2.0 is now generating large CAS values, larger than 32 bits, which may be what's causing the problem. CAS does work correctly when passing zero for the CAS value. Any chance of this getting fixed?

Member

jskorpan commented Aug 13, 2012

Could you please provide a minimal reproduction test for this. Thanks!

On 9 aug 2012, at 22:09, et1337 notifications@github.com wrote:

Ubuntu 12.04 64-bit. We were using ultramemcache quite happily with Couchbase 1.8.1. I seem to recall 1.8.1 generating relatively short CAS values (maybe 5 digits). 2.0 is now generating large CAS values, larger than 32 bits, which may be what's causing the problem. CAS does work correctly when passing zero for the CAS value. Any chance of this getting fixed?


Reply to this email directly or view it on GitHub.

etodd commented Aug 14, 2012

Not sure what exactly you need, but here's what I did:

  1. Download and install Couchbase 2.0 on localhost from here: http://www.couchbase.com/download?next=true

  2. Run the following commands and you should see a discrepancy between the actual CAS value and the one that ultramemcache reports.

    telnet localhost 11211
    set test 0 0 5
    value
    STORED
    gets test
    VALUE test 0 5 1557003786629
    value
    END
    ^]
    quit
    Connection closed.
    python
    import umemcache
    c = umemcache.Client('localhost:11211')
    c.connect()
    c.gets('test')
    ('value', 0, 2225625477L)

I actually performed all these steps on Mountain Lion 64 bit, so it seems to be a cross-platform issue.

I Wiresharked it, and that second value (2225625477) does in fact get sent back to the memcache server correctly if you use the cas() function. It's just not getting the right CAS value in the first place for some reason.

Member

jskorpan commented Aug 14, 2012

I'm gonna need to ask for a test to reproduce this problem as my setup when
performing the very same steps doesn't render the same result.

Please have a look in tests\tests.py and add function which causes this to
fail

//JT

2012/8/14 et1337 notifications@github.com

Not sure what exactly you need, but here's what I did:

  1. Download and install Couchbase 2.0 on localhost from here:
    http://www.couchbase.com/download?next=true
    2.

    Run the following commands and you should see a discrepancy between
    the actual CAS value and the one that ultramemcache reports.

    telnet localhost 11211
    set test 0 0 5
    value
    STORED
    gets test
    VALUE test 0 5 1557003786629
    value
    END
    ^]
    quit
    Connection closed.
    python
    import umemcache
    c = umemcache.Client('localhost:11211')
    c.connect()
    c.gets('test')
    ('value', 0, 2225625477L)

I actually performed all these steps on Mountain Lion 64 bit, so it seems
to be a cross-platform issue.

I Wiresharked it, and that second value (2225625477) does in fact get sent
back to the memcache server correctly if you use the cas() function. It's
just not getting the right CAS value in the first place for some reason.


Reply to this email directly or view it on GitHubhttps://github.com/esnme/ultramemcache/issues/8#issuecomment-7724846.

Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@esn.me
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me

etodd commented Aug 14, 2012

The testCas() function in tests/tests.py fails for me when connecting to Couchbase 2.0. It gives an 'EXISTS' error code.

The test DOES pass when connecting to a Couchbase 1.8.1 server, I'm assuming because the server generates a much smaller CAS value (example: 356556 as opposed to 369667802784).

You got it working with Couchbase 2.0? On what OS?

Member

mthurlin commented Aug 14, 2012

1557003786629 & 0xffffffff
2225625477L

Something somewhere is treating the cas-value as 32-bit :)

Member

jskorpan commented Aug 14, 2012

Thanks for the input Markus

I think I've discovered a rather nasty type-o affecting all platforms but
Windows:
https://github.com/esnme/ultramemcache/blob/master/lib/mcdefs.h#L39
https://github.com/esnme/ultramemcache/blob/master/lib/mcdefs.h#L40

That can't be right :)

//JT

2012/8/14 Markus Thurlin notifications@github.com

1557003786629 & 0xffffffff
2225625477L

Something somewhere is treating the cas-value as 32-bit :)


Reply to this email directly or view it on GitHubhttps://github.com/esnme/ultramemcache/issues/8#issuecomment-7726404.

Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@esn.me
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me

Member

jskorpan commented Aug 14, 2012

Patch is in Master, please have a try. Btw, I noticed that two other
unrelated tests fail against Couchbase, I'll look into that later on.

//JT

2012/8/14 Jonas Tärnström jonas.tarnstrom@esportnetwork.com

Thanks for the input Markus

I think I've discovered a rather nasty type-o affecting all platforms but
Windows:
https://github.com/esnme/ultramemcache/blob/master/lib/mcdefs.h#L39
https://github.com/esnme/ultramemcache/blob/master/lib/mcdefs.h#L40

That can't be right :)

//JT

2012/8/14 Markus Thurlin notifications@github.com

1557003786629 & 0xffffffff
2225625477L

Something somewhere is treating the cas-value as 32-bit :)


Reply to this email directly or view it on GitHubhttps://github.com/esnme/ultramemcache/issues/8#issuecomment-7726404.

Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@esn.me
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me

Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@esn.me
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me

etodd commented Aug 14, 2012

Patch worked for me on Couchbase. Thank you! :)

Member

jskorpan commented Aug 14, 2012

Great, closing issue. I suppose we would recommend everyone using umemcache to take the upgrade to 1.4

@jskorpan jskorpan closed this Aug 14, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment