Save redirect not working and occasionally failing to save

[dwightgunning]

The initial problem I have is that the "save and translate next block" doesn't navigate forward to the next block, it simply saves the translations on the current page and redisplays it.

After hitting save, it is possible to move forward manually using the numbered page links which is what I've asked my translator to do.

However the bigger problem is that after repeating the above for several pages, on the ~6th page of translations the save button redirects back to the Language selection page and the most recent set of translations are lost. Previously saved pages are retained.

Seems likely to be an issue with session/caching but I have no idea where to start....

Django 1.4 and Rosetta 0.6.8.

I experience the issue under two server configurations:

• nginx in front of Gunicorn
• 'runserver' (daemonised under screen)

Configuration:

ROSETTA_STORAGE_CLASS = 'rosetta.storage.CacheRosettaStorage'
SESSION_COOKIE_SECURE = False
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
'LOCATION': 'dwight-dev',
}
}

[mbi]

I see, this is most probably the same issue as #51, i.e. using the CacheRosettaStorage with a multi-process wsgi server and the LocMemCache backend, each server process having a distinct cache instance.

Could you please try to either use a shared cache backend (such as the Memcache) or switching to the SessionRosettaStorage and see if the problem goes away?

[dwightgunning]

I've quickly installed django-redis-cache (as I already run Redis as part of this application) but still the Save button is not moving the page forward and I still have the problem with 'runserver'.

Seems potentially time bound. Now that I test it a different way... by repeatedly using the Save button on page 1, which as I explained continuously reloads page 1.

• Short durations seems to work continuously (I've hit save 20+ times).
• If I wait for a couple minutes then the problem bites and I get redirected back to the Language select page.

[mbi]

Have you specified a TIMEOUT [1] value when setting up your Redis backend? Could I ask you to try to specify a large TIMEOUT value (e.g. 86400) and see if the problem persists after waiting a couple minutes?

1: https://docs.djangoproject.com/en/dev/topics/cache/?from=olddocs#cache-arguments

[dwightgunning]

Some progress. By keeping an eye on cache keys in Redis, I can confirm the error appears right after the cache expires.

Somewhat frustrating is that I can't seem to get the TIMEOUT parameter on the redis cache configuration to work. I tried setting it to 24hrs (86400) as suggested, and also to -1 which the django-redis-cache docs indicate should mean the keys never expire.

Despite this I can see that a TTL is still applied to the cache keys on creation. Also interesting/frustrating is that the TTL isn't restarted when saving or refreshing the page. So the session time is fixed from the very first time the session cache is established, not the most recent request.

Seems like it could be the way Rosetta interacts with the cache?

[mbi]

Well, Rosetta uses the "official" Django cache API, i.e. cache.set() and cache.get()
Could you please try to patch your rosetta/storage.py file, and setting an explicit timeout in the cache.set() call in the CacheRosettaStorage, something like:

cache.set(self._key_prefix + key, val, 86400)

[dwightgunning]

That looks a helluva lot more like it....

r.ttl(':1:ad88af1df9794d8c6c0112ffb5b1cd96d21cc706rosetta_i18n_lang_name')
86375L

From what I see in the django docs, it should default to the cache TIMEOUT configuration as you originally suggested. So I think the usage in rosetta's CacheRosettaStorage looks correct. So I'll probably take this one to the django-redis-cache project. Right?

On the other hand, I don't have a save button that navigates fwd. Shall I raise a separate issue for this?

Thanks much for your help with this - I sure learnt a thing or two :-)

[mbi]

Thanks for the feedback, I'm going to add an explicit cache timeout on that cache.set(). I'm going to look into that save button thing…

[Gesias]

Thanks for this, experienced the same thing myself.
Just a best-practice question. Do I put the changes into the code locally myself or patch it by checking out this commit?

[aasensiog]

Hi all,
I had the same problem with a system nginx + uwsgi without using any cache.
Rosetta worked fine locally but had an unpredictable behaviour in other machines.

As Readme.rst says:
'''
TL;DR: if you run Django with gunincorn, mod-wsgi or other multi-process environment, the Django-default CACHES LocMemCache backend won't suffice: use memcache instead, or you will run into issues.
'''

The problem was solved, for me, installing memcached on server/s and adding the proper config in settings:
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
'LOCATION': '127.0.0.1:11211',
}
}

Good luck!

[vgaicuks]

Thank you @aasensiog a lot.

[dwightgunning]

Housekeeping close.