Re: Memcached+SASL going down after multiple request with wrong credentials.

Hey, That's still missing some information. How is the daemon itself exiting/crashing/etc? I need at least a small hint to go on. thanks, -Dormando On Tue, 25 Apr 2017, seenivasan g wrote: > Hello Dormando, > Thanks for the response. > > Note: We are running memcached on non-root user account.

Re: With latest versions, can I have just one cache to store small objects (several tens of bytes) and large objects (~20MiB) together?

responses inline. On Wed, 26 Apr 2017, Min-Zhong "John" Lu wrote: > Hi again, > > When I was on my previous topic, I came to realize this question might be > asked too. > > Background story: > I have employed memcached around its 1.4.x-ish version. And I've always had a > need to store objects

Re: Culprit of intermittent & transient item-too-large set failures, and why favoring slab reassignment over memory allocation?

Well I must be doomed and I feel embarrassed now. TL;DR: It's an error on my side (part pylibmc, part our engineering problem), not memcached's. Long story: So, it turns out that some of our computation instances have pylibmc 1.5.0 and some pylibmc 1.5.1. I already knew pylibmc 1.5.1 had

With latest versions, can I have just one cache to store small objects (several tens of bytes) and large objects (~20MiB) together?

Hi again, When I was on my previous topic , I came to realize this question might be asked too. *Background story:* I have employed memcached around its 1.4.x-ish version. And I've always had a need to store objects larger than

Re: Culprit of intermittent & transient item-too-large set failures, and why favoring slab reassignment over memory allocation?

Nice. Unfortunate there's a regression there :( Hopefully it's been looked at? I'll try to prioritize getting more of the logging hooks done, since this would've been resolved a lot more easily by you if the errors were more easily accessible. Most clients hide errors or make it difficult to

Memcached Binary protocol

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 .

Re: Memcached Binary protocol

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

Re: SASL Configuration

https://blog.couchbase.com/sasl-memcached-now-available/ On Wednesday, December 16, 2015 at 8:14:34 PM UTC-8, Cody Robertson wrote: > > Hello! > > I'm having difficulty finding information on where I can configure some of > the SASL options (mechanisms, etc). Can anyone point me in the right >

Re: Memcached+SASL going down after multiple request with wrong credentials.

Hi Jack, I see the exported "MEMCACHED_SASL_PWDB" is not set as expected. If you look at your supplied logs, the memcached is still looking for the DB under /etc/sasldb2, which is wrong in your case. Try to echo the env variable MEMCACHED_SASL_PWDB and verify its really getting set to $HOME/

Re: With latest versions, can I have just one cache to store small objects (several tens of bytes) and large objects (~20MiB) together?

> > No, i'm not talking about performance trouble with 63 slab classes (and I > think I mistook that -- it should be 62 per PR 97). I'm talking about that in > old versions when we could have two hundred classes, which I believed could > result in memory inefficiency. > > (and in old versions if

Re: Memcached Binary protocol

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

Re: Memcached Binary protocol

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:

Re: Memcached Binary protocol

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

Re: Memcached Binary protocol

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

Re: Memcached Binary protocol

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

Re: Memcached Binary protocol

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,