Skip Menu |

This queue is for tickets about the Cache-Memcached-Fast CPAN distribution.

Report information
The Basics
Id: 48153
Status: rejected
Priority: 0/
Queue: Cache-Memcached-Fast

People
Owner: Nobody in particular
Requestors: MALA [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Unimportant
Broken in: 0.16
Fixed in: (no value)



Subject: get_multi implementation assumes that the response keys get returned back with the same order as requests.
Your get_multi() implementation assumes that the response keys get returned back with the same order as requests. This doesn't work when the server returns them in a different order. Sample code and response in Cache::Memcached::Fast 0.16 http://subtech.g.hatena.ne.jp/mala/20090724/1248423743 I think this is not critical, but Cache::Memcached hasn't this bug.
Subject: get_multi_order_problem.pl
#!/usr/bin/perl use Cache::Memcached::Fast; use Data::Dumper; if (my $pid = fork()) { MyMemcached->run(port => 11212); } else { sleep 1; } my $cache = Cache::Memcached::Fast->new({ servers => ["127.0.0.1:11212"] }); print Dumper $cache->get_multi("key1", "key2"); print Dumper $cache->get_multi("key2", "key1"); package MyMemcached; use base qw(Net::Server); sub process_request { my $self = shift; while (<STDIN>) { s/\r?\n$//; print "VALUE key1 0 4\r\nkey1\r\nVALUE key2 0 4\r\nkey2\r\nEND\r\n"; } }
Yes, C::M::F depends on values returned in the same order as requested. This is how memcached works now, and this shouldn't change in the future. Your test case behaves differently from memcached, so C::M::F doesn't work with it. Requiring the client to lookup every reply in a dictionary to see what requested key it corresponds to would make the client *unnecessarily* slow. The whole idea of returning positive replies *only* is a mistake: we still have to send back keys, and compare them on the client side to see what replies we've got. It would be much better to do a one-to-one correspondence and send NOT_FOUND on occasion, so that the matching could be done simply by counting. Comparing keys is slow, looking them up in the dictionary is even more so. C::M::F avoids this as much as it can.