SASL requires more steps]
>
> ... 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 shouldn't
ates done or STEP if SASL requires more steps]
>
> ... 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
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 with SASL and
> > libmemcached clients we would need binary protocol support right?
> >
>
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 compatibili
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&
from conn_waiting 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
authentica
nection 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
t; checked 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 p
hink 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
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,
rote:
>
> > 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
>
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 le
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 consist
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 qu
I can test with large string quickly. In the test app I may be sending
fewer bytes, but in my real app I am sending way more bytes.
FYI: I started with SASL auth, which was failing intermittently. After
debugging I realized something is not right with binary protocol, then I
disabled the SASL
t likely a bug 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 pict
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
or?
On Wed, 26 Apr 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)
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
than a packet). At
>> Facebook, our main way of talking to memcached (mcrouter) doesn't even
>> support 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-d
way of talking to memcached (mcrouter) doesn't even
> support 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 some
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 ad
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
g 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 of parsing in the Server side, but it seems that I need
> to test both cases.
>
> Thanks again f
, 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
> 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
>
pport 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 ng
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.
Bu
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
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 is
Comment #1 on issue 320 by ari...@gmail.com: increment with initial value
using binary protocol always returns 22 bytes value with get
http://code.google.com/p/memcached/issues/detail?id=320
Possible fix in this github pull request:
https://github.com/memcached/memcached/pull/39
--
You
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 320 by ari...@gmail.com: increment with initial value using
binary protocol always returns 22 bytes value with get
http://code.google.com/p/memcached/issues/detail?id=320
* What steps will reproduce the problem?
1. Send a
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
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:
http://docs.libmemcached.org/me
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
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
Hi,
On Feb 19, 2013, at 12:14 AM, dormando 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 did. I am not su
> > 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
> would be made for bo
Hi,
On Feb 18, 2013, at 7:11 PM, dormando 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 wo
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 som
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, F
Hi Brian,
Yep, these interaction were made between pylibmc and Memcached at
localhost, 11211. I just skipped something that Dormando said, sorry, but
he might have nailed it: "It might look mixed up if you're doing this over
localhost and there's no lag. Try it over the internet or use a qdisc to
> On Feb 18, 2013, at 6:03 PM, Diogo Baeder 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 responds back with
Hi,
On Feb 18, 2013, at 6:03 PM, Diogo Baeder 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 responds back with
whate
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 said
> 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
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, the
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.
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
en 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 unknown
> command error.(Text protocol work
Comment #6 on issue 275 by bongjae@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
This is similar to the issue which I reported before.
http://groups.google.com/group/memcached/browse_thread/thread/1a40b776e35bbf08/17b7c53cd914e7f7
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(ca
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 #3 on issue 275 by mojid...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
Ubuntu 10.04.4 LTS,memcached 1.4.13
Red Hat Enterprise Linux Server release 5.5 (Tikanga),memcached 1.4.11
==
The server response
Updates:
Status: needinfo
Comment #2 on issue 275 by ingen...@gmail.com: binary protocol
TOUCH,GAT,GATQ bug
http://code.google.com/p/memcached/issues/detail?id=275
(No comment was entered for this change.)
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.
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New 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)
TimeUnit.SECONDS.sleep(1);
S
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 reque
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 ret
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 and
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 #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
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 an
Comment #9 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
The recvfom() use 0 as SIZE and NULL as BUFFER. According to manual, that
call will consume the incoming packet. Without it
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 #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 #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 #5 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
Hello again! I (the author of http://gitorious.org/snitchaser) has
disappeared for nearly 10 month, and now come back to continue
Comment #9 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
ok i got it , thank you .
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 undocument
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:it
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
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.
MA
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 no
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 no
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 #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 , wh
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 ”
Hi,
On 19 Jan., 23:38, Dagobert 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:
> https://github.com/memcached/memcached/commit/5100e7af8802b8170adb8a7...
> These two
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
Hi,
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:
https://github.com/memcached/memcached/commit/5100e7af8802b8170adb8a7fc66232481048eab2#L1R2404
These two lines with APPEND_STA
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)
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 and
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.)
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
Comment #2 on issue 106 by pi3orama: binary protocol parsing can cause
memcached server lockup
http://code.google.com/p/memcached/issues/detail?id=106
The issue is studied and solved under the help of Snitchaser:
http://gitorious.org/snitchaser
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->rlbyt
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
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 #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 nu
; > I posted this to the libmemcached mailing list a while ago and didn't
> > >> > get a response, but this list is a lot more active so I'm hoping
> > >> > someone here will have answers for me. :)
>
> > >> > I've taken some time to
t;> > get a response, but this list is a lot more active so I'm hoping
> >> > someone here will have answers for me. :)
>
> >> > I've taken some time to work on porting our code from using the PHP
> >> > PECL memcache extension to using the PECL
gt; > Hi guys,
>>
>> > I posted this to the libmemcached mailing list a while ago and didn't
>> > get a response, but this list is a lot more active so I'm hoping
>> > someone here will have answers for me. :)
>>
>> > I've taken som
rom 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.
>
> > Her
so I'm hoping
> someone here will have answers 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 libmemc
d functionality that libmemcached
has to offer, but I'm running into some issues using the binary
protocol.
Here is my code:
addServers($servers);
$m->setOption(Memcached::OPT_DISTRIBUTION,
Memcached::DISTRIBUTION_CONSISTENT);
$m->setOption(Memcached::OPT_CONNECT_TIMEOUT
1 - 100 of 123 matches
Mail list logo
