You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the problem
Have noticed that when saving a large array to the EE cache (associative array, about 5K rows, each row holding an array with 40 columns - generates a cache file of about 6Mbytes) the operation sometimes faults and the file written is truncated / corrupted. This faulting is observable in the cPanel resources plot ('faults' are recorded concurrent with when the file write operation fails).
Loss of this file is consequential for the add-on it is being written by.
How To Reproduce
Steps to reproduce the behavior:
Tricky to find a 100% reliable mechanism - currently behaviour is observed on a site with sufficiently large data requirements that triggers creation of the very large array to be cached, and has been seen with the site running on more than one servers - which suggests it is not a hardware issue.
Error Messages
None directly - EE does not appear to report that there was an issue writing the file. The issue is detected through the adverse consequences for site operations when the cache file is corrupted only, and via the cPanel Resources fault event log.
Screenshots / Videos / Template Code
The array is being saved to the cache file cache_log and reflects the total number of images stored by JCOGS Image on the site concerned - so typically grows to a size reflective of the total image estate for the site and stays there, but the file is periodically rewritten (data within the array being saved does change over time). Here you can see that the log file reduced from 1.3Mbytes to 327Kbytes over the course of a day or so. What has been observed is that when the file gets to a sufficiently large size, the probability of the write operation faulting (and all cached information being lost) goes up - subsequent attempts to re-save the file capture only changes made to image estate after the fault, hence why image cache file 'regrows' over time.
Concurrent with this the events that result in the loss of this file content appear to match exactly 'fault' reports for the server.
Apparently the date / time of this final 'fault' marker on this graph coincide with the time of creation of one instance of the cache_log file (a new file is created when existing one not found).
Environment Details:
Version: 7.3.x and 7.4.x (issue has been under review for some time)
PHP Version 8.1
Possible Solution
Looking at finding an alternative technical solution for that will avoid having to cache this array.
The text was updated successfully, but these errors were encountered:
Description of the problem
Have noticed that when saving a large array to the EE cache (associative array, about 5K rows, each row holding an array with 40 columns - generates a cache file of about 6Mbytes) the operation sometimes faults and the file written is truncated / corrupted. This faulting is observable in the cPanel resources plot ('faults' are recorded concurrent with when the file write operation fails).
Loss of this file is consequential for the add-on it is being written by.
How To Reproduce
Steps to reproduce the behavior:
Tricky to find a 100% reliable mechanism - currently behaviour is observed on a site with sufficiently large data requirements that triggers creation of the very large array to be cached, and has been seen with the site running on more than one servers - which suggests it is not a hardware issue.
Error Messages
None directly - EE does not appear to report that there was an issue writing the file. The issue is detected through the adverse consequences for site operations when the cache file is corrupted only, and via the cPanel Resources fault event log.
Screenshots / Videos / Template Code
The array is being saved to the cache file
cache_log
and reflects the total number of images stored by JCOGS Image on the site concerned - so typically grows to a size reflective of the total image estate for the site and stays there, but the file is periodically rewritten (data within the array being saved does change over time). Here you can see that the log file reduced from 1.3Mbytes to 327Kbytes over the course of a day or so. What has been observed is that when the file gets to a sufficiently large size, the probability of the write operation faulting (and all cached information being lost) goes up - subsequent attempts to re-save the file capture only changes made to image estate after the fault, hence why image cache file 'regrows' over time.Concurrent with this the events that result in the loss of this file content appear to match exactly 'fault' reports for the server.
![Screenshot 2024-04-18 at 09 52 29](https://private-user-images.githubusercontent.com/13821249/323560000-b6a2e608-457a-4710-b530-d9fe8b398e22.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MTkyNTUyNTIsIm5iZiI6MTcxOTI1NDk1MiwicGF0aCI6Ii8xMzgyMTI0OS8zMjM1NjAwMDAtYjZhMmU2MDgtNDU3YS00NzEwLWI1MzAtZDlmZThiMzk4ZTIyLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA2MjQlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwNjI0VDE4NDkxMlomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTJkZWZhZTQzMDk0NzU2YmMwYzc4Y2ZkMmFlYmI5ZmNiZTgwODI3YjU1OTI5YTk4NWVkYmFhOWVkMjAwNmYzMzgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.5YHOTDz_XDw32Nmp8RMfKgbtzuAluZBpOOGD4GFGIrA)
Apparently the date / time of this final 'fault' marker on this graph coincide with the time of creation of one instance of the cache_log file (a new file is created when existing one not found).
Environment Details:
Possible Solution
Looking at finding an alternative technical solution for that will avoid having to cache this array.
The text was updated successfully, but these errors were encountered: