Timeout error with python-memcached

[David Ziegler]

The following code works fine:

from gevent import monkey
monkey.patch_all()

import memcache

client = memcache.Client(['127.0.0.1:11211'], debug=True)
client.set('spam','eggs',30)
assert client.get('spam') == 'eggs'

but if I try to call it line by line in the interpreter I get this
error:

>>> client = memcache.Client(['127.0.0.1:11211'], debug=True)
>>> client.set('spam','eggs',30)
MemCached: MemCache: inet:127.0.0.1:11211: connect: timed out.
Marking dead.

Not sure if this is a bug in gevent or python-memcached, but it seems
that the socket dies. I'm on snow leopard running the latest versions
of gevent and python-memcached.

[Denis Bilenko]

Hi David,

The interactive interpreter is not monkey patched, so when it waits
for the input
the event loop is not running, causing the connection to time out. If
you do need
to try out things interactively, you can checkout gevent.backdoor
module which exposes
the interactive interpreter over a TCP socket that you can connect to
using telnet.

Cheers,
Denis.

[Örjan Persson]

Seems to work just fine for me on Debian. Both with python 2.5 and 2.6
as well as python-memcached version 1.40 and 1.44.

[Örjan Persson]

On Fri, Apr 9, 2010 at 13:58, Denis Bilenko <denis....@gmail.com> wrote:
> Hi David,
>
> The interactive interpreter is not monkey patched, so when it waits
> for the input
> the event loop is not running, causing the connection to time out. If
> you do need
> to try out things interactively, you can checkout gevent.backdoor
> module which exposes
> the interactive interpreter over a TCP socket that you can connect to
> using telnet.

Ah, of course. I wonder why there wasn't any errors reported for me.
It looks like everything got patched correctly. But when I tried a
client.get('spam'), the same debug message triggered.

[David Ziegler]

Ah, thanks for clearing that up. Thought I was going crazy.

[David Ziegler]

On a related note, gevent seems to work fine when I run my
application, but when I try to run my test suite, the event loop
appears to die. It's a typical Django test suite so I have a bunch of
tests for each app. If I run an app individually, the tests pass. But
if I try to run the tests consecutively, the tests for the first app
will pass and all the others will fail because the event loop stops
running.

For example:

./manage.py test cachebot --settings=settings.test
----------------------------------------------------------------------
Ran 426 tests in 23.854s

OK
Destroying test database...

./manage.py test activity cachebot --settings=settings.test
----------------------------------------------------------------------
Ran 429 tests in 15.627s

FAILED (failures=390)
Destroying test database...

I've looked into it and the reason the tests are failing is because
the memcache lookup is timing out and returning None. Is there a way
to restart the event loop, and why is it dying? Thanks for the help,
and sorry if these are dumb questions, I'm new to libevent.

[Denis Bilenko]

Hi David,

You should post the actual traceback, otherwise it's impossible to
guess what's going on.

On Sun, Apr 11, 2010 at 7:24 AM, David Ziegler <david....@gmail.com> wrote:
> On a related note, gevent seems to work fine when I run my
> application, but when I try to run my test suite, the event loop
> appears to die. It's a typical Django test suite so I have a bunch of
> tests for each app. If I run an app individually, the tests pass. But
> if I try to run the tests consecutively, the tests for the first app
> will pass and all the others will fail because the event loop stops
> running.
>
> For example:
>
> ./manage.py test cachebot --settings=settings.test
> ----------------------------------------------------------------------
> Ran 426 tests in 23.854s
>
> OK
> Destroying test database...
>
>
> ./manage.py test activity cachebot --settings=settings.test
> ----------------------------------------------------------------------
> Ran 429 tests in 15.627s
>
> FAILED (failures=390)
> Destroying test database...
>
>
> I've looked into it and the reason the tests are failing is because
> the memcache lookup is timing out and returning None.

So it probably got disconnected. Without seeing the code it's hard to say why.
Most likely some blocking operation was called for too long. Does
django test forks new processes?

In my apps, when I need to have a persistent connection to something,
I use a dedicated greenlet that
- restarts the connection when it dies
- is the only greenlet that has access to the connection, so it can
be fuxored by simultaneous
users. The greenlets that want to use the connection post requests
into this greenlet's Queue. If the connection is full-duplex, you
might want to use 2 greenlets

> Is there a way to restart the event loop, and why is it dying?

Why do you think that the event loop died? If it did, you would see
this message:
http://bitbucket.org/denis/gevent/src/tip/gevent/hub.py#cl-169

Cheers,
Denis.

[David Ziegler]

After further debugging, the problem seems to be the fact that Django
uses a single cache instance, which keeps a persistent connection to
memcache. Not sure why it was getting disconnected, but either way I
guess I should follow your suggestion and use a dedicated greenlet for
it. Thanks!