Skip to content
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

Changing session storage type doesn't appear to work #4495

Closed
craigh opened this issue Sep 24, 2020 · 6 comments
Closed

Changing session storage type doesn't appear to work #4495

craigh opened this issue Sep 24, 2020 · 6 comments
Assignees
Labels
Milestone

Comments

@craigh
Copy link
Member

craigh commented Sep 24, 2020

this is a problem in 3.1.0 ONLY

when changing session storage type, the value is properly updated in the config but it doesn't switch the type of storage actually.

I suspect the cache simply must be properly cleared so the config is reloaded.

@craigh craigh added the Bug label Sep 24, 2020
@craigh craigh added this to the 3.1.0 milestone Sep 24, 2020
@craigh craigh self-assigned this Sep 24, 2020
@craigh
Copy link
Member Author

craigh commented Sep 24, 2020

If I delete the cache/prod/sessions dir then the method changes

@craigh
Copy link
Member Author

craigh commented Sep 26, 2020

I'm not sure the previous comment is actually true.

The problem I think lies in my lack of understanding of the container and the rebuild process. The same problem that affects module installation and other container-related operations. Before Sy5 it was pretty clear how the container worked - everything worked from the files in the cache folder... delete the cache and it rebuilds and changes the operation/behavior. Since Sy5, that seems changed - the container seems held in memory and doesn't seem to affect change very quickly... sometimes several page loads or leaving a site and returning are required before the cached files are rebuilt and change the operation/behavior. This seems random and unpredictable and makes changing the container very difficult.

@Guite
Copy link
Member

Guite commented Sep 26, 2020

@craigh
Copy link
Member Author

craigh commented Sep 26, 2020

Screen Shot 2020-09-26 at 9 30 08 AM

it appears I am using OPcache without understanding it. So perhaps the problem is that and not Sy5...

@craigh
Copy link
Member Author

craigh commented Sep 26, 2020

indeed. disabling OPcache seems to have cleared the problem. behavior is now as expected...

the problem of course is how to deal with this in a generic way in production for zikula installations.

this seems promising https://ma.ttias.be/how-to-clear-php-opcache/

opcache_reset();

@craigh
Copy link
Member Author

craigh commented Oct 4, 2020

closed by #4507

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants