memcached node js client
I am using memcached node js client. I am not getting the JSON output when
performing the get operation on it. Here is my code
memcached.get(id, function( err, result ){
if( err ) console.error( err );
console.log( result );
});
and the output is
a:2:{s:7:"passkey";s:40:"8c779538d8c4ed54cf8a89d1e59518557febf0ac";s:7:"userkey";s:7:"5b9ce84";}
How to get the userkey from this output or how to get the output as json?
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: memcached node js client
On Wed, Oct 07, 2015 at 03:57:50AM -0700, nith...@cloudion.net wrote:
> I am using memcached node js client. I am not getting the JSON output when
> performing the get operation on it. Here is my code
>
> memcached.get(id, function( err, result ){
> if( err ) console.error( err );
> console.log( result );
> });
> and the output is
>
> a:2:{s:7:"passkey";s:40:"8c779538d8c4ed54cf8a89d1e59518557febf0ac";s:7:"userkey";s:7:"5b9ce84";}
> How to get the userkey from this output or how to get the output as json?
Looks like your problem is that you haven't put JSON into memcached.
That looks a bit like PHP serialisation format. Maybe call json_encode
in your PHP. If you can't do that, it looks like people have created
some nasty node.js php unserializers. Like
https://github.com/naholyr/js-php-unserialize
David
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Memcached appears to fail when LAN disconnects from the Internet
When I disable SASL it seems to work correctly. I'm using version 1.4.24. On Tuesday, October 6, 2015 at 9:55:52 PM UTC-7, Jim Horning wrote: > > I have two conditions that seem to make memcached fail. I have a > memcached server and a few clients all on the same subnet: 192.168.1.X, > where these devices use NAT to get to the Internet. > > 1. If I start up the sever/clients AND the Internet connection is not > available (i.e. I disconnect the LAN to my router) then memcached does not > appear to work. My server starts, initializing some of my memcached > variables and its VERY slow between each set() variable call. And, the > clients appear to not be able to read the server. > > 2. Or, similarly, if I startup WITH an Internet connection (and all is > working well) and then I disconnect from the Internet, then memcached fails. > > Note: I have a "default" gateway with genmask of 0.0.0.0 assigned to eth0, > and 192.168.1.0 with genmask of 255.255.255.0 assigned to eth0. > > If I delete the "default" route when I've lost the Internet connection > then all of a sudden memcached works just fine. > > Any ideas? > -- --- You received this message because you are subscribed to the Google Groups "memcached" group. To unsubscribe from this group and stop receiving emails from it, send an email to memcached+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: memcached node js client
Thank u David.. It works
On Wed, Oct 7, 2015 at 7:16 PM, David Sheldon
wrote:
> On Wed, Oct 07, 2015 at 03:57:50AM -0700, nith...@cloudion.net wrote:
> > I am using memcached node js client. I am not getting the JSON output
> when
> > performing the get operation on it. Here is my code
> >
> > memcached.get(id, function( err, result ){
> > if( err ) console.error( err );
> > console.log( result );
> > });
> > and the output is
> >
> >
> a:2:{s:7:"passkey";s:40:"8c779538d8c4ed54cf8a89d1e59518557febf0ac";s:7:"userkey";s:7:"5b9ce84";}
> > How to get the userkey from this output or how to get the output as json?
>
>
> Looks like your problem is that you haven't put JSON into memcached.
> That looks a bit like PHP serialisation format. Maybe call json_encode
> in your PHP. If you can't do that, it looks like people have created
> some nasty node.js php unserializers. Like
> https://github.com/naholyr/js-php-unserialize
>
> David
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "memcached" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/memcached/zD0KEYI38NA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> memcached+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
---
You received this message because you are subscribed to the Google Groups
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to memcached+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Check for orphaned items in lru crawler thread
any luck? > On Oct 6, 2015, at 12:23 AM, Dormando wrote: > > ah. I pushed two more changes earlier. should fix mem_requested. just > cosmetic stuff though > >> On Oct 6, 2015, at 12:13 AM, Scott Mansfield wrote: >> >> Oops, looks like the latest code didn't get into production today. I'm >> building it again, same plan as before. >> >>> On Monday, October 5, 2015 at 4:38:00 PM UTC-7, Dormando wrote: >>> Looking forward to the results. Thanks for getting on this so quickly. >>> >>> I think there's still a bug in tracking requested memory, and I want to >>> move the stats counters to a rollup at the end of a page move. >>> Otherwise I think this branch is complete pending any further stability >>> issues or feedback. >>> >>> On Mon, 5 Oct 2015, Scott Mansfield wrote: >>> >>> > I just put the newest code into production. I'm going to monitor it for a >>> > bit to see how it behaves. As long as there's no obvious issues I'll >>> > enable reads in a few hours, which are an order of magnitude more >>> > traffic. I'll let you know what I find. >>> > >>> > On Monday, October 5, 2015 at 1:29:03 AM UTC-7, Dormando wrote: >>> > It took a day of running torture tests which took 30-90 minutes to >>> > fail, >>> > but along with a bunch of house chores I believe I've found the >>> > problem: >>> > >>> > https://github.com/dormando/memcached/tree/slab_rebal_next - has a >>> > new >>> > commit, specifically this: >>> > >>> > https://github.com/dormando/memcached/commit/1c32e5eeff5bd2a8cc9b652a2ed808157e4929bb >>> > >>> > >>> > It's somewhat relieving that when I brained this super hard back in >>> > january I may have actually gotten the complex set of interactions >>> > correct, I simply failed to keep typing when converting the >>> > comments to >>> > code. >>> > >>> > So this has been broken since 1.4.24, but hardly anyone uses the >>> > page >>> > mover apparently. It's survived a 5 hour torture test (that I wrote >>> > in >>> > 2011!) once fixed (previously dying after 30-90 minutes). So please >>> > give >>> > this one a try and let me know how it goes. >>> > >>> > If it goes well I can merge up some other fixes from PR list and >>> > cut a >>> > release, unless someone has feedback for something to change. >>> > >>> > thanks! >>> > >>> > On Thu, 1 Oct 2015, dormando wrote: >>> > >>> > > I've seen items.c:1183 reported elsewhere in 1.4.24... so >>> > probably the bug >>> > > was introduced when I rewrote the page mover for that. >>> > > >>> > > I didn't mean to send me a core file: I mean if you dump the core >>> > you can >>> > > load it in gdb and get the backtrace (bt + thread apply all bt) >>> > > >>> > > Don't have a handler for convenient attaching :( >>> > > >>> > > didn't get a chance to poke at this today... I'll need another >>> > day to try >>> > > it out. >>> > > >>> > > On Thu, 1 Oct 2015, Scott Mansfield wrote: >>> > > >>> > > > Sorry for the data dumps here, but I want to give you >>> > everything I have. I found 3 more addresses that showed up in the dmesg >>> > logs: >>> > > > >>> > > > $ for addr in 40e013 40eff4 40f7c4; do addr2line -e memcached >>> > $addr; done >>> > > > >>> > > > .../build/memcached-1.4.24-slab-rebal-next/slabs.c:265 >>> > (discriminator 1) >>> > > > >>> > > > .../build/memcached-1.4.24-slab-rebal-next/items.c:312 >>> > (discriminator 1) >>> > > > >>> > > > .../build/memcached-1.4.24-slab-rebal-next/items.c:1183 >>> > > > >>> > > > >>> > > > I still haven't tried to attach a debugger, since the frequency >>> > of the error would make it hard to catch it. Is there a handler that I >>> > could add in to dump the stack trace when it segfaults? I'd get a core >>> > dump, but they would be HUGE and contain confidential information. >>> > > > >>> > > > >>> > > > Below are the full dmesg logs. Out of 205 servers, 35 had dmesg >>> > logs after a memcached crash, and only one crashed twice, both times on >>> > the original segfault. Below is the full unified set of dmesg logs, from >>> > which you can get a sense of frequency. >>> > > > >>> > > > >>> > > > [47992.109269] memcached[2798]: segfault at 0 ip >>> > 0040e007 sp 7f4d20d25eb0 error 4 in memcached[40+1d000] >>> > > > >>> > > > [48960.851278] memcached[2805]: segfault at 0 ip >>> > 0040e007 sp 7f3c30d15eb0 error 4 in memcached[40+1d000] >>> > > > >>> > > > [46421.604609] memcached[2784]: segfault at 0 ip >>> > 0040e007 sp 7fdb94612eb0 error 4 in memcached[40+1d000] >>> > > > >>> > > > [48429.671534] traps: memcached[2768] general protection >>> > ip:40e01
