Comment #23 on issue 363 by i...@nodesocket.com: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
This was a race condition fixed with:
https://github.com/memcached/memcached/commit/e73bc2e5c0794cccd
Comment #22 on issue 363 by pavel.hl...@profimedia.cz: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Hi, I have exactly same problem described here. My error message is:
MemcachePool::set(): Serve
Comment #21 on issue 363 by pavel.hl...@profimedia.com:
MemcachePool::get(): Server 127.0.0.1 (tcp 11211, udp 0) failed with:
Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Hi, I have exactly same problem described here. My error message is:
MemcachePool::set(): Se
Can you give me a list (privately, if need be) of a few things:
- The exact OS your server is running (centos/redhat release/etc)
- The exact kernel version (and where it came from? centos/rh proper or a
3rd party repo?)
- Full list of your 3rd party repos, since I know you had some random
french
To that note, it *is* useful if you try that branch I posted, since so far
as I can tell that should emulate the .17 behavior.
On Thu, 8 May 2014, dormando wrote:
> > I am just speculating, and by no means have any idea what I am really
> > talking about here. :)
> > With 2 threads, still solid,
> I am just speculating, and by no means have any idea what I am really talking
> about here. :)
> With 2 threads, still solid, no timeouts, no runaway 100% cpu. Its been days.
> Increasing from 2 threads to 4 does not generate any more traffic or
> requests to memcached. Thus I am speculating pe
I am just speculating, and by no means have any idea what I am really
talking about here. :)
With 2 threads, still solid, no timeouts, no runaway 100% cpu. Its been
days. Increasing from 2 threads to 4 does not generate any more traffic or
requests to memcached. Thus I am speculating perhaps it
That doesn't really tell us anything about the nature of the problem
though. With 2 threads it might still happen, but is a lot less likely.
On Wed, 7 May 2014, notificati...@commando.io wrote:
> Bumped up to 2 threads and so far no timeout errors. I'm going to let it run
> for a few more days,
Bumped up to 2 threads and so far no timeout errors. I'm going to let it
run for a few more days, then revert back to 4 threads and see if timeout
errors come up again. That will tell us the problem lies in spawning more
than 2 threads.
On Wednesday, May 7, 2014 5:19:13 PM UTC-7, Dormando wrote
Hey,
try this branch:
https://github.com/dormando/memcached/tree/double_close
so far as I can tell that emulates the behavior in .17...
to build:
./autogen.sh && ./configure && make
run it in screen like you were doing with the other tests, see if it
prints "ERROR: Double Close [somefd]". If it
Changing from 4 threads to 1 seems to have resolved the problem. No
timeouts since. Should I set to 2 threads and wait and see how things go?
On Tuesday, May 6, 2014 12:07:08 AM UTC-7, Dormando wrote:
>
> and how'd that work out?
>
> Still no other reports :/ a few thousand more downloads of .19
and how'd that work out?
Still no other reports :/ a few thousand more downloads of .19...
On Sun, 4 May 2014, notificati...@commando.io wrote:
> I'm going to try switching threads from 4 to 1. This host web2 is on the only
> one I am seeing it on, but it also is the only hosts that gets any
>
I'm going to try switching threads from 4 to 1. This host web2 is on the
only one I am seeing it on, but it also is the only hosts that gets any
real traffic. Super frustrating.
On Sunday, May 4, 2014 10:12:08 AM UTC-7, Dormando wrote:
>
> I'm stumped. (also, your e-mails aren't updating the tic
I'm stumped. (also, your e-mails aren't updating the ticket...).
It's impossible for a connection to get into the closed state without
having event_del() and close() called on the socket. A socket slot isn't
event_add()'ed again until after the state is reset to 'init_state'.
There was no code pa
Damn it, got network timeout. CPU 3 is using 100% cpu from memcached.
Here is the result of stat to verify using new version of memcached and
libevent:
STAT version 1.4.19
STAT libevent 2.0.18-stable
On Saturday, May 3, 2014 11:55:31 PM UTC-7, notifi...@commando.io wrote:
>
> Just upgraded all
Just upgraded all 5 web-servers to memcached 1.4.19 with libevent 2.0.18.
Will advise if I see memcached timeouts. Should be good though.
Thanks so much for all the help and patience. Really appreciated.
On Friday, May 2, 2014 10:20:26 PM UTC-7, memc...@googlecode.com wrote:
>
> Updates:
>
Updates:
Status: Invalid
Comment #20 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Any repeat crashes? I'm going to close this. it looks like remi
ship
Comment #19 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Turned out the upstream packager somehow built .18 against libevent-1.4.13
despite eariler versions b
I am in IRC now.
Seeing stderr logged over and over again in screen session:
http://i.imgur.com/FrXRGZW.png
No timeouts with ./mc_conn_tester.pl though high CPU load in memcached
process. See htop: http://i.imgur.com/qw93Jgv.png
On Wednesday, April 30, 2014 5:08:27 PM UTC-7, memc...@googlecode
Comment #18 on issue 363 by i...@nodesocket.com: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Nothing yet, no output in the screen process.
--
You received this message because this project is co
Comment #17 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Been a bit under a day. Any output in your screen session yet?
--
You received this message because th
Comment #16 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Er clarifying some typos:
"It would then enter drive_machine() with the state already in conn_closed"
Updates:
Status: Accepted
Comment #15 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
So it turned out that c->state was set to "conn_closed".
Looking at
Comment #14 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
heh.. if I'm not in IRC you might want to update here :P
I made a few more mistakes... I should've ask
I had to restart memcached. Here is the result of gdb, hope it helps
without stepping through.
https://gist.github.com/nodesocket/31d32d838c08c47aa0d7
On Tuesday, April 29, 2014 7:27:09 AM UTC-7, notifi...@commando.io wrote:
>
> It is happening right now, heading into IRC.
>
> On Monday, April 2
It is happening right now, heading into IRC.
On Monday, April 28, 2014 4:51:31 PM UTC-7, memc...@googlecode.com wrote:
>
>
> Comment #13 on issue 363 by notifica...@commando.io: MemcachePool::get():
>
> Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
> http://code.google.com/
Comment #13 on issue 363 by notifica...@commando.io: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Thanks for the update. I am now running from source from the home
directory. When it happens aga
Comment #12 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Just more notes: we worked this out a bit in IRC.
He's not running from a source build... which I thin
Comment #11 on issue 363 by notifica...@commando.io: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Speak of the devil. Just got an alert:
E_NOTICE: MemcachePool::get(): Server 127.0.0.1 (tcp 11211
Comment #10 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
I'm planning on releasing 1.4.19 sometime tomorrow. So far I haven't had
any other reports of a simil
Comment #9 on issue 363 by i...@nodesocket.com: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
So far no errors, very strange. Will keep you posted, thanks for the help,
really appreciated.
--
Y
Comment #8 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
no luck?
--
You received this message because this project is configured to send all
issue notificati
Comment #7 on issue 363 by jus...@commando.io: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
Will do, I expect this issue to popup sometime tomorrow. I have gdb ready
when it does.
--
You recei
Comment #6 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
I'm really concerned that you're getting mc_conn_tester to fail each time
but can still connect via te
Comment #5 on issue 363 by i...@nodesocket.com: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
I had to restart memcached, but of the errors (this is a production host),
however I ran:
stats and
Comment #4 on issue 363 by i...@nodesocket.com: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
The memcached timeout issues are back on the same host, here is the output
of mc_conn_tester.pl.
➜
Comment #3 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
I'm deeply suspicious if mc_conn_tester.pl is failing 100% but you can
successfully telnet to it :/
Comment #2 on issue 363 by notifica...@commando.io: MemcachePool::get():
Server 127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
It always failed, but after restarting memcached so far no problems. Will
advise if anything come
Comment #1 on issue 363 by dorma...@rydia.net: MemcachePool::get(): Server
127.0.0.1 (tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
I know we talked it over in IRC a bit, but one more question:
does mc_conn_tester.pl always fail, or is
Status: New
Owner:
Labels: Type-Defect Priority-Medium
New issue 363 by i...@nodesocket.com: MemcachePool::get(): Server 127.0.0.1
(tcp 11211, udp 0) failed with: Network timeout
http://code.google.com/p/memcached/issues/detail?id=363
We just upgraded to memcached 1.4.18 using PHP 5.4.27
40 matches
Mail list logo
