roundtrip in the protocol but this could be solved with
> mget/mset.
>
> On Thu, 9 May 2019, dormando wrote:
>
> > Indeed we would. SASL is actually a text based protocol, as it's used in
> > SMTP and similar. That shouldn't be too bad.
> >
> > On Thu, 9 May 2019
]
>
> ... extra roundtrip in the protocol but this could be solved with
> mget/mset.
>
> On Thu, 9 May 2019, dormando wrote:
>
> > Indeed we would. SASL is actually a text based protocol, as it's used
> in
> > SMTP and similar. That sho
e:
>
> > Hey Dormando,As of now only binary protocol supports SASL.
> > Correct me if I am wrong but to ensure compatibility with SASL and
> > libmemcached clients we would need binary protocol support right?
> >
> >
> > Thanks and Regards,Om Kale
> >
&
Indeed we would. SASL is actually a text based protocol, as it's used in
SMTP and similar. That shouldn't be too bad.
On Thu, 9 May 2019, Om Kale wrote:
> Hey Dormando,As of now only binary protocol supports SASL.
> Correct me if I am wrong but to ensure compatibility wit
Hey Dormando,
As of now only binary protocol supports SASL.
Correct me if I am wrong but to ensure compatibility with SASL and
libmemcached clients we would need binary protocol support right?
Thanks and Regards,
Om Kale
On Thu, May 9, 2019 at 2:58 PM dormando wrote:
> Yo,
>
> A
Yo,
Any of you out there really _like_ the binary protocol? Aside from the
features it gives (CAS everywhere, pipelining, etc).
just thinkin' through some things.
Thanks,
-Dormando
--
---
You received this message because you are subscribed to the Google Groups
"memcached&q
ing to conn_read
36: going from conn_read to conn_parse_cmd
<36 Read binary protocol data:
<360x80 0x20 0x00 0x00
<360x00 0x00 0x00 0x00
<360x00 0x00 0x00 0x00
<360x00 0x02 0x00 0x00
<360x00 0x00 0x00 0x00
<360x00 0x00 0x00 0x00
authenticated() in cmd 0x
t established. All requests after the
> connection setup is fine.
>
> On Wed, 26 Apr 2017, watul123 wrote:
>
> > I think the binary protocol just works as expected, there is nothing
> to do with length as well, it was my test program where I
ecked when the connection is first established. All requests after the
> connection setup is fine.
>
> On Wed, 26 Apr 2017, watul123 wrote:
>
> > I think the binary protocol just works as expected, there is nothing to
> do with length as well, it was my test progra
ink the binary protocol just works as expected, there is nothing to do
> with length as well, it was my test program where I commented out the below
> line
> "memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, 1);"
>
> After fixing(un commenting) this line, no matt
I think the binary protocol just works as expected, there is nothing to do
with length as well, it was my test program where I commented out the below
line
"memcached_behavior_set(cache, MEMCACHED_BEHAVIOR_BINARY_PROTOCOL, 1);"
After fixing(un commenting) this line, no matter w
Never mind, while debugging I commented out some lines and forgot to
un-comment those. After fixing it, I don't see the bad magic issue.
Importantly, the increase in the length of key:value in test program
returns the success. So the inconsistency of binary protocol is no issue
anymore, now I
26, 2017 at 10:50:33 PM UTC-7, Dormando wrote:
>
> Your key isn't over 256 bytes is it?
>
> On Wed, 26 Apr 2017, watul123 wrote:
>
> > Ok, thanks. Let me debug in that direction. I will update the thread
> with my findings.
> >
> > BTW, if I increase the length
Your key isn't over 256 bytes is it?
On Wed, 26 Apr 2017, watul123 wrote:
> Ok, thanks. Let me debug in that direction. I will update the thread with my
> findings.
>
> BTW, if I increase the length of key and value in my test program with binary
> protocol then I consistently
Ok, thanks. Let me debug in that direction. I will update the thread with
my findings.
BTW, if I increase the length of key and value in my test program with
binary protocol then I consistently get CONNECTION FAILURE with below
output on memcached side
<36 new binary client connection.
Ok.
The binary protocol is tested pretty well so it's *probably* something in
your program, but I won't rule out a bug on the server either. The binary
protocol is in heavy usage in a bunch of places though.
On Wed, 26 Apr 2017, watul123 wrote:
> I can test with large string quic
in how you're using the binary protocol, but it's
hard to say from here. Somehow you're writing fewer bytes to the socket
than you told the binary protocol to receive.
On Wed, 26 Apr 2017, watul123 wrote:
> Yes I am 100% sure.
> When the binary protocol is in picture then only this happens, ot
Yes I am 100% sure.
When the binary protocol is in picture then only this happens, otherwise
same test program with same argument runs perfect. I debugged a lot before
posting to this group. I am with you on the fact the binary protocol has
nothing to do with the timeouts, but it is the one
2017, Atul Waghmare wrote:
> Hi there,
>
> I am facing one issue with memcached binary protocol. Whenever I force the
> memcached to use the binary protocol, my application get occasional timeouts
> and occasional success. The percentage of failure(set timeouts) is more than
>
Hi there,
I am facing one issue with memcached binary protocol. Whenever I force the
memcached to use the binary protocol, my application get occasional
timeouts and occasional success. The percentage of failure(set timeouts) is
more than 80% when the memcached spawn with binary protocol
I'm looking to implement a client for the binary protocol. I take it there
is no padding between memcached requests, and that the keys are values are
arbitrary lengths. So, if I send two requests, and the key for the first
one is an odd number of bytes, that means the second request
, and it *doesn't matter* because the
batching happens anyway.
I don't have any experience with the memcached-defined binary protocol,
but I think there's probably something similar going on here. You can
verify by using a tool like tcpdump or ngrep to see what goes into each
packet when you do
-gets on the client side, and it *doesn't matter* because the
batching happens anyway.
I don't have any experience with the memcached-defined binary protocol,
but I think there's probably something similar going on here. You can
verify by using a tool like tcpdump or ngrep to see what goes
Comment #10 on issue 275 by semnan...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
https://code.google.com/p/memcached/issues/detail?id=275
not fixed i use install make test and give me this page link. i send using
php test poster to qa. please check it. debian wheezy dot deb memcached
Comment #11 on issue 275 by dorma...@rydia.net: binary protocol
TOUCH,GAT,GATQ bug
https://code.google.com/p/memcached/issues/detail?id=275
that's not a version of memcached.
--
You received this message because this project is configured to send all
issue notifications to this address
.
But, the longer latency may not be a real issue unless it exceeds some
threshold that the end users can notice.
So, now I'm trying to use multi-get as much as possible.
Actually, I have thought that Binary protocol would be always better than
ascii protocol since binary protocol
can reduce the burden
that Binary protocol would be always better than
ascii protocol since binary protocol
can reduce the burden of parsing in the Server side, but it seems that I need
to test both cases.
Thanks again for the comments, and I will share the result if I get some
interesting or useful data
Hello,
For now, I'm trying to evaluate the performance of memcached server by
using several client workloads.
I have a question about multi-get implementation in binary protocol.
As I know, in ascii protocol, we can send multiple keys in a single request
packet to implement multi-get
multi-gets on the client side, and it *doesn't matter* because the
batching happens anyway.
I don't have any experience with the memcached-defined binary protocol, but
I think there's probably something similar going on here. You can verify by
using a tool like tcpdump or ngrep to see what goes
Hello,
For now, I'm trying to evaluate the performance of memcached server by using
several client workloads.
I have a question about multi-get implementation in binary protocol.
As I know, in ascii protocol, we can send multiple keys in a single request
packet to implement multi-get
Updates:
Status: Fixed
Comment #2 on issue 320 by dorma...@rydia.net: increment with initial value
using binary protocol always returns 22 bytes value with get
http://code.google.com/p/memcached/issues/detail?id=320
Merged fix.
--
You received this message because this project
Updates:
Status: Fixed
Comment #9 on issue 275 by dorma...@rydia.net: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
this got merged a year ago... forgot to close the issue. doing so now.
--
You received this message because this project
Hi,
On Feb 18, 2013, at 7:11 PM, dormando dorma...@rydia.net wrote:
1) libmemcached requests 2 keys
2) memcached responds with 1 key
3) libmemcached sends no-op packet
4) memcached responds with 2nd key, no-op packet
Assuming one server and binary protocol... a single write to the socket
Hi,
On Feb 19, 2013, at 12:14 AM, dormando dorma...@rydia.net wrote:
Both keys go out okay, but the no-op at the end seems to go out in a
separate packet. I've noticed this on several installs using libmemcached,
verified with tcpdump/etc.
I didn't write this part of the binary code, Trond
Its been a while since I looked at that code but if my memory is correct
we're using the quiet' mode of the get requests so that it won't send not
found results. The noop is then used as an internal marker so that you
know on the receiving side that you've received all of the responses from
the
This is correct. You use the no-op packet to be sure you're not waiting
for any more responses, since you're not going to get miss packets for
missing keys.
No reason for it to be a separate write/packet though.
On Tue, 19 Feb 2013, Trond Norbye wrote:
Its been a while since I looked at that
Agreed, I'll take a look and see why that is happening.
From looking at the code I can see where it is happening, I just need to find
out if there was a reason for it. The default value for io_key_prefetch is
zero, which is what is causing the flush to happen:
Hi guys,
Good news: everything's working now, here, with your help I figured out how
to deal with this situation; However, I opted by forcing the ordering of
the requests and responses in my proxy, because of the specific needs for
the proxy. (I could explain in details, but I thought it would be
Hi guys,
I'm getting a rather strange behaviour when I try to issue a get-multi on
memcached, so I'm not sure this is a problem with my understanding of how
the protocol was specified or if it's an issue with either pylibmc or
libmemcached.
What I expect:
As I understand it, for multi-get,
However, after trying to follow this behaviour in a proxy I'm building, this
order of interactions is not being respected; So, what I did afterwards, to
assert that something strange was going on, was to fire up Wireshark and
listen for memcached requests and
responses. Here's a sample of
Hi Dormando,
So, I've tested Memcached by sending direct byte blocks to it in the order
I expected it to behave, and indeed it works, as you said it would:
https://gist.github.com/diogobaeder/4982425
I have no clue why libmemcached does that switch in the middle, but I
understood what you
Hi,
On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote:
I have no clue why libmemcached does that switch in the middle, but I
understood what you said about not expecting things to happen in an exact
order
Are you sure the data is on the same server? Libmemcached
On Feb 18, 2013, at 6:03 PM, Diogo Baeder diogobae...@gmail.com wrote:
I have no clue why libmemcached does that switch in the middle, but I
understood what you said about not expecting things to happen in an exact
order
Are you sure the data is on the same server? Libmemcached
Yep, agreed, Dormando, not a problem, just different from my initial
expectations. I'll just have to figure out how to use Tornado in my favor,
to build this part, and deal correctly with the asynchronicity. :-)
Cheers!
__
Diogo Baeder
http://diogobaeder.com.br
On Tue,
Guess what: I just built a fake Memcached server, to answer hardcoded
values (same as before) to a get_multi op for pylibmc, with normally
ordered batches (2 reqs, 1 noop, 2 resp, 1 noop), and it worked. So, in the
end, it seems like forcing the ordering is not what is causing me troubles,
it's
Comment #7 on issue 275 by uzza...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
Here is a patch that solves the problem. process_bin_touch() was reading
only header without extra fields, so exptime was always 0.
Attachments
Comment #8 on issue 275 by uzza...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
P.S. Send pull request at github with the same code.
and
gat command with binary protocol, it seemed that they didn't work
correctly.
* Memcached v1.4.10
1. verbosity
When I sent the request to the server, the server returned unknown
command error.(Text protocol works fine)
(I made the request based on
http://code.google.com/p/memcached
Comment #4 on issue 275 by dorma...@rydia.net: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
If you sleep for 2 seconds instead of one, it should work. Memcached's
internal clock updates once per second, so if you want to see things change
Comment #5 on issue 275 by mojid...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
cache.set(x, xxx, 3);
cache.touch(x, 1)
while(true){
TimeUnit.SECONDS.sleep(1);
System.out.println(cache.get(x));
}
===output==
xxx
xxx
Comment #1 on issue 275 by ingen...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
What server is in use? There is no checking of server responses.
Hi,
I am trying to implement a memcached client based on Java for
improving performance.
Most of commands worked fine. But when I tested verbosity, touch and
gat command with binary protocol, it seemed that they didn't work
correctly.
* Memcached v1.4.10
1. verbosity
When I sent the request
Hi,
I am trying to implement a memcached client based on Java for improving
performance.
When I tested verbosity, touch and gat command with binary protocol, it
seemed that they didn't work correctly.
* Memcached v1.4.10
1. verbosity
When I sent the request to the server, the server returned
Updates:
Status: Fixed
Comment #2 on issue 107 by dorma...@rydia.net: binary protocol can only
parse 1 command within a recieved udp / tcp buffer
http://code.google.com/p/memcached/issues/detail?id=107
wow this is ancient.
fix for this is currently sitting in my for_148 branch
Updates:
Status: Fixed
Comment #12 on issue 106 by dorma...@rydia.net: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
think this was merged up. closing.
Comment #10 on issue 106 by dorma...@rydia.net: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
The incoming packet is consumed in try_read_udp(), so if you get into a
conn_close state after reading one packet, calling
Comment #11 on issue 106 by pi3or...@gmail.com: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
I think you are right.
In my first patch (Comment 1), the recvfrom() call is critical because in
that situation, if a UDP
Updates:
Status: Started
Owner: trond.no...@gmail.com
Comment #8 on issue 106 by dorma...@rydia.net: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
I just pulled a patch similar to this into my 1.4.7 tree
Comment #6 on issue 106 by dorma...@rydia.net: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
Can you issue a patch against 1.6.0-beta1? Or were you talking about 1.4.5,
not 1.3.5?
Comment #7 on issue 106 by pi3or...@gmail.com: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
Ok. 1.6.0-beta1 still suffer from this problem, the principle is similar.
Following patch solve it (I thought).
--- ./daemon
Comment #2 on issue 187 by trond.no...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
You should use the key field, but I don't think memcached 1.4.5 supports
stats cachedump in the binary protocol
Comment #4 on issue 187 by sarow...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
stats cachedump has two arguments , one for slab_id ,one for limit . I
have use the key field , but it seems nothing changed . May
Comment #3 on issue 187 by sarow...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
stats cachedump has two arguments , one for slab_id ,one for limit . I
have use the key field , but it seems nothing changed . May
Updates:
Status: Invalid
Comment #5 on issue 187 by dsalli...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
I think the documentation is pretty clear:
MUST NOT have extras.
MAY have key.
MUST
Comment #6 on issue 187 by sarow...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
I have read this documentation
stats items , stats maps , stats settings are work well
but stats cachedump has another two arguments
Comment #7 on issue 187 by sarow...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
I have send one packet like that
opcode:0x10
key:cachedump10
i get Not Fonud
I send another like this
opcode:0x10
key:items
i got
Comment #8 on issue 187 by dsalli...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
what should i do ,when i want cachedump 1 0 ?
Spend some time asking yourself why you are trying to use an undocumented
debug
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 187 by sarow...@gmail.com: no example for stats cachedump in
binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
In memcached Protocol-binary.xml , it has nothing with “stats cachedump ”
command， i
Comment #1 on issue 187 by sarow...@gmail.com: no example for stats
cachedump in binary-Protocol
http://code.google.com/p/memcached/issues/detail?id=187
in memcached code：
typedef protocol_binary_request_no_extras protocol_binary_request_stats;
stats request is no extras , where should i
Hi,
On 19 Jan., 23:38, Dagobert honkma...@googlemail.com wrote:
I have a strange phenomenon: The test t/binary.t fails from 1.4.4 for
me on Solaris 9 Sparc with Sun Studio 12. I nailed it down to this
commit causing the failure:
Comment #4 on issue 106 by airat.ha...@gmail.com: binary protocol parsing
can cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
may be this specific issue is solved by the provided patch (haven't tried),
but in general the problem remains.
Even after
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 176 by evanjelias: Binary protocol: delete_hits and delete_misses
not incremented?
http://code.google.com/p/memcached/issues/detail?id=176
Hi folks,
When using the binary protocol, it seems that the delete_hits
Updates:
Status: Fixed
Comment #1 on issue 176 by dsallings: Binary protocol: delete_hits and
delete_misses not incremented?
http://code.google.com/p/memcached/issues/detail?id=176
This was fixed in 83af8a219b42e0c46a8a7cfd5def27444c6fe78b (not yet in a
release)
Updates:
Owner: eric.d.lambert
Comment #3 on issue 106 by eric.d.lambert: binary protocol parsing can
cause memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
this looks similar to the problem with issue 158, so i'll take a look at
this
Updates:
Owner: eric.d.lambert
Comment #1 on issue 107 by eric.d.lambert: binary protocol can only parse 1
command within a recieved udp / tcp buffer
http://code.google.com/p/memcached/issues/detail?id=107
(No comment was entered for this change.)
Comment #1 on issue 106 by pi3orama: binary protocol parsing can cause
memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
The root cause of this issue is try_read_udp() never reset c-rbytes.
The processing of conn_nread minus c-rbytes by c-rlbytes, so if extra
Comment #5 on issue 48 by a...@enyim.com: binary protocol incr on text
returns success 0
http://code.google.com/p/memcached/issues/detail?id=48
i'm not sure which version includes this fix, but both 1.4.3 and 1.4.4 give
me a status code 0 (SUCCESS) when
trying to increment non numeric
Comment #6 on issue 48 by dsallings: binary protocol incr on text returns
success 0
http://code.google.com/p/memcached/issues/detail?id=48
I see status code 6 and the error text there. 6 == bad value for
incr/decr. I believe this
is correct. This change went in as 1.4.0-rc1-2-gcce46e8
Comment #7 on issue 48 by a...@enyim.com: binary protocol incr on text
returns success 0
http://code.google.com/p/memcached/issues/detail?id=48
yeah, sorry i forgot that the status is supposed to be 16bit not 8.
--
You received this message because you are listed in the owner
or CC fields
memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m
for me. :)
I've taken some time to work on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here
from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost
functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached
code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array
issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached::OPT_CONNECT_TIMEOUT, 500);
$m
memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new
running into some issues using the binary
protocol.
Here is my code:
?php
$servers = array(array('localhost', '11211'));
$m = new Memcached();
$m-addServers($servers);
$m-setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m-setOption(Memcached
on porting our code from using the PHP
PECL memcache extension to using the PECL memcached extension so we
can take advantage of all the advanced functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
?php
Comment #4 on issue 3 by dsallings: Textual delete command w/ expire time
noreply in binary protocol version
http://code.google.com/p/memcached/issues/detail?id=3
I've pushed a branch for this (finally... this is an old one).
--
You received this message because you are listed
Updates:
Status: Fixed
Comment #7 on issue 3 by trond.norbye: Textual delete command w/ expire
time noreply in binary protocol version
http://code.google.com/p/memcached/issues/detail?id=3
(No comment was entered for this change.)
--
You received this message because you
Hello,
I am working through writing a simple Java UDP client; apparently none
of the clients already written support UDP, sigh.
The example response in the GET section of the binary protocol shows
Key as None, meaning it is omitted in the response.
Field(offset) (value)
Magic
On Oct 22, 1:24 pm, Robert Buck buck.rober...@gmail.com wrote:
However, in the prior section it states:
Response (if found):
MUST have extras.
MAY have key.
MAY have value.
Under which conditions will the key be present? Under which conditions
will it not. Can
Thank you Dustin.
On Thu, Oct 22, 2009 at 4:36 PM, Dustin dsalli...@gmail.com wrote:
On Oct 22, 1:24 pm, Robert Buck buck.rober...@gmail.com wrote:
However, in the prior section it states:
Response (if found):
MUST have extras.
MAY have key.
MAY have value.
The memcached FAQ links to this document describing the binary protocol:
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol
Unfortunately, this document is out of date compared to the
protocol-binary.xml that ships with 1.4.0. For example, it is missing
various opcodes like
On Aug 3, 7:37 pm, Mat Hostetter mjhostet...@gmail.com wrote:
The memcached FAQ links to this document describing the binary protocol:
http://code.google.com/p/memcached/wiki/MemcacheBinaryProtocol
Unfortunately, this document is out of date compared to the
protocol-binary.xml
Issue 48 demonstrates that we don't check delta status from within
binary incr calls. I've written tests for both incr and decr to show
the problem, but I don't have a way to report the error.
Currently, I'm using einval, but that's just kind of wrong since
that's more to do with the input
96 matches
Mail list logo
