-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
503 Service Unavailable error when requesting 'admin/fastlyCdn_Edge_Dictionary/ListAll' #163
Comments
We are looking into it. |
Hello I've attempted to reproduce the issue on Magento versions (2.2.2 and 2.2.3) and both Fastly versions 1.2.48 and 1.2.49 (last) and was unable to reproduce the issue. I've used clean version with only domain set (without any config) and our working version (with old config) in testing. If possible please check logs for server errors and let us know if this is something related to part of the fastly code so we will look into it. also if you used active_version=8, can you let us know what config you have adjusted in version 8 (have you used magento admin to update config or did you make custom adjustments?) Regards, |
I can confirm that this is an issue happening in a magneto-cloud pro environment. I am seeing this error on this call on every single page load in the admin: /admin/admin/fastlyCdn_Vcl/getBackends/key/6a6c898626bdabaec07b2e044c54e7c2e9b309e1b44df8151a81dceff3b19ba8/ Exception: Noticed exception 'Exception' with message 'Warning: session_start(): Failed to read session data: user (path: /var/lib/php/sessions) in /app/7alebf6ygqtlm/vendor/magento/framework/Session/SessionManager.php on line 189' in /app/7alebf6ygqtlm/vendor/magento/framework/App/ErrorHandler.php:61 I am also not sure why its looking for sessions in var/lib/php/sessions. Also I am on the latest fastly extension 1.2.49. Thoughts? |
@jordanvector what happens if you revert to an older version ? |
@vvuksan good question, I can't remember where started but I am pretty sure it was with the last 2 versions. I can revert 2 versions and report back |
That would be great @jordanvector as we are not able to reproduce this. |
@vvuksan I have noticed this typically after a deployment on magento cloud just fyi |
Does the issue clear itself or does it persist ? |
the issue persists but I was able to get rid of it for a period of time by adding a dictionary in the backend options |
That's helpful. Just to confirm to workaround around the issue all you had to do was Edge Dictionary ? |
@vvuksan correct the workaround for me was to add an edge dictionary |
Hi @jordanvector , After adding edge dictionaries and browsing through admin, issue no longer persists? Trace you have pasted has nothing to do with the Fastly, as it is not mentioned. Application broke because it couldn't start the PHP session as indicate. Reason behind that seems to be because session path, in this case |
@udovicic so we are definitely using redis for session storage which is very odd that it is looking at /var/lib/php/sessions. Here is the quick line from env.php (minus connection values) 'session' => |
@udovicic upon further investigation sessions are be written to redis (so not quite sure whats going on there). I have a ticket open with magento as well, will update if I hear anything from them |
@udovicic after digging into this it seems like my issue specifically was not linked to fastly. the magento cloud php.ini by default has sessions configured to save to the filesystem by default which was causing the error that I was seeing. By default it looks like this in php.ini: session.save_handler => files => files When I updated the php.ini to save to redis like this: session.save_handler = redis It seemed to resolve the issue. I still have a ticket that magento has not responded to so if they come back with any other suggestions I will report them here. |
The issue is caused by Redis session blocking mechanism. The Cm/RedisSession library has a variable which limits the maximum number of processes that can wait for lock on one session. By default it's value is 6. The default value leads to errors on Magento frontend/backend when, for example, a web page makes several AJAX requests to Magento. That's what you see when navigate to Stores > Configuration > System: Fastly extension starts sending several AJAX requests to Magento and you reach the maximum concurrency limit. When it happens, Magento responds with 503 error and you can find "Area code is not set" errors in the var/report/ directory. To avoid the issue, you have to increase the max_concurrency value in app/etc/env.php:
If you're a Magento Cloud user, you mustn't edit env.php manually, but add the SESSION_CONFIGURATION variable with Redis configuration in JSON format. You can get more details by submitting a support request. |
@vvuksan it's not a fastly/magtento2 bug, you can close the issue. |
wow thanks :-) |
Thanks for the info @yyevgenii! I'll test this when I find some time to work on this project again (probably next week). |
I confirmed, that after changing session settings issue was fixed. { Note: your environment settings can be differ |
Can confirm the fix from @agorbulin. I first tried to change the concurrency value using the And it solves the problem indeed! |
Increasing The burden of responsibility here seems to fall to the fastly module, if reducing the number of AJAX requests is feasible? |
Can you elaborate on performance issues on the front end ? I'm a bit surprised that one cannot make more than 6 AJAX requests. |
Sounds like a lock contention. |
We'll look into doing this differently. |
Getting the same issue here on Cloud. Using those redis settings caused users to be logged out intermittently so that's a no go for us unfortunately. |
We have addressed this in #177. Fixes were released as part of 1.2.54. |
Just tested by removing the |
Hi guys
Yesterday we enabled Fastly on a staging environment of the Magento Cloud.
But we sometimes see errors popping up in random adminhtml pages under Stores > Configuration (not only in Advanced > System), this error is displayed in a red box:
A technical problem with the server created an error. Try again to continue what you were doing. If the problem persists, try again later.
When looking through the Network tab of my inspector, I can see that some XHR requests to the Fastly module throws a 503 error which causes this problem.
I can see 3 similar XHR requests, two of them work and one fails.
The ones which work:
The one which fails with a 503 error:
And I also sometimes see this one fail with a 503 error:
It's a bit random these errors, sometimes it's the first one, sometimes the other one, sometimes even both, and then sometimes no errors, really strange behavior.
Looking at the actual contents of the response, we see something like this (it feels like this is a server error somehow, but no idea how to debug this):
Extra info which might be relevant:
fastly/magento2
version 1.2.48Any ideas what can cause this or how we can solve this?
If there are no errors, those request return valid looking json strings, so I don't think the problem is in the Fastly module itself, but actually on the server side. If we have to report this to the Magento Cloud support instead, please let us know.
Thanks!
The text was updated successfully, but these errors were encountered: