<p>My solution to this was to swap memcache for Redis. I realize that doesn't resolve <em>why</em> memcache wasn't working for us, but swapping it corrected this issue.</p>

<p>My best guess is either:</p>

<ol>
<li>We were caching data to memcache that was too large for it to optimally handle. </li>
<li>Memcache was being overwhelmed when asked to cache the thumbnails for images that Craft was generating.</li>
</ol>

<p>These are completely unfounded, but just some best guesses on what was happening.</p>

CC BY-SA 4.0
2018-07-30T20:27:16.917Z
2018-07-30T20:27:16.917Z
Aaron Bushnell
<p>I can't figure out why, but when I'm connected to a memcache server the thumbnail generation process in Assets hangs for long periods of time, the <code>getElements</code> process throws 403 errors, the generating thumbnails throw 401 errors and then the user is signed out.</p>

<p>This happens in 2 different AWS environments and on my local environment configured using MAMP. In total, three different memcache servers (production, stage, local) have this same thing occur.</p>

<p>The only thing I can find in the logs that seems like it could be related is an error message that reads:</p>

<pre><code>Tried to restore session from a cookie, but the given login name does not match the given uid.
UID: LONG_UID_HASH_HERE and loginName: MY_EMAIL_ADDRESS.
</code></pre>

<p>I'm currently running Craft CMS 2.6.3019 (most current version of 2.x at the moment).</p>

<p><strong>Edit:</strong> I also wanted to mention these assets all reside in an Amazon S3 bucket. Thought that might be relevant here, too.</p>

<p><strong>Edit 2:</strong> I forced <code>hasThumb()</code> to always return <code>false</code> by <a href="https://github.com/craftcms/cms/blob/develop-v2/src/models/AssetFileModel.php#L309-L321" rel="nofollow noreferrer">commenting out these lines</a>. The thumbnails don't generate 401 errors (because no thumbnails are being generated and the placeholder images are being used instead). And <code>getElements</code> runs much quicker, but it stills throws 403 errors after clicking around for some time.</p>

<users><control-panel><session>
Generating thumbnails when using a memcache server for session storage frequently signs users out
# Generating thumbnails when using a memcache server for session storage frequently signs users out

(Asked by: username_0 on 2018-07-27)

I can't figure out why, but when I'm connected to a memcache server the thumbnail generation process in Assets hangs for long periods of time, the getElements process throws 403 errors, the generating thumbnails throw 401 errors and then the user is signed out.
This happens in 2 different AWS environments and on my local environment configured using MAMP. In total, three different memcache servers (production, stage, local) have this same thing occur.
The only thing I can find in the logs that seems like it could be related is an error message that reads:
Tried to restore session from a cookie, but the given login name does not match the given uid.
UID: LONG_UID_HASH_HERE and loginName: MY_EMAIL_ADDRESS.

I'm currently running Craft CMS 2.6.3019 (most current version of 2.x at the moment).
Edit: I also wanted to mention these assets all reside in an Amazon S3 bucket. Thought that might be relevant here, too.
Edit 2: I forced hasThumb() to always return false by commenting out these lines. The thumbnails don't generate 401 errors (because no thumbnails are being generated and the placeholder images are being used instead). And getElements runs much quicker, but it stills throws 403 errors after clicking around for some time.

**Tags:** users, control-panel, session

---

## 1 answers

### Answer by username_0 on 2018-07-30. Score: 1 | Accepted answer

My solution to this was to swap memcache for Redis. I realize that doesn't resolve *why* memcache wasn't working for us, but swapping it corrected this issue.

My best guess is either:

1. We were caching data to memcache that was too large for it to optimally handle.
2. Memcache was being overwhelmed when asked to cache the thumbnails for images that Craft was generating.

These are completely unfounded, but just some best guesses on what was happening.


---

