I don't think its SASL, if I am following the memcached logs correctly then
its failing while doing a read from FD(it gets zero bytes which results in
READ_ERROR). Look at the following back to back fail and success. Read
fails well before the SASL(auth and etc) comes into picture, *but
Sounds like the underlying SASL service is failing sometimes? I don't
think there's anything in the memcached code that would cause this.
On Sat, 29 Apr 2017, watul123 wrote:
> I am using same connection once the connection is established. What I see so
> far is the inconsistency in the
I am using same connection once the connection is established. What I see
so far is the inconsistency in the establishing the connection itself. As
pasted above in the logs, for same password/user name, same setup, same
test program, same memcached bin, if I run the test program multiple times
Are you reusing connections, or re-SASL'ing every time? I wonder if the
underlying sasl daemon/mechanism is failing. SASL stuff is only ever
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
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 what length
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
No, its just like below
const char* key = "abczadfg";
const char* value = "valuetestapp";
and
I am using the this to ste the value "rc = memcached_set(cache, key,
strlen(key), value, strlen(value), (time_t)0, flags);"
Thanks,
Atul
On Wednesday, April 26, 2017 at 10:50:33 PM UTC-7,
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 get CONNECTION
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.
36:
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 quickly. In the
Looks like the protocol is getting out of sync somehow.
conn_waiting only means it's waiting to read more bytes from the socket
from a set. Then it looks like the client doesn't send anymore bytes,
times out, then closes the socket (-> conn_read -> conn_closing).
It's most likely a bug in how
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
Any way to get more information about the timeouts you're seeing?
There's nothing in the protocol that would cause "timeouts", but bugs
somewhere could cause clients to hang waiting on more data I guess.
You're sure they're timeouts and not some other kind of error?
On Wed, 26 Apr 2017, Atul
13 matches
Mail list logo
