• Resolved wabetainfo

    (@wabetainfo)


    Uncaught Error: Call to undefined function __() in /home/website/public_html/wp-admin/includes/file.php:16 Stack trace: #0 /home/website/public_html/wp-content/object-cache.php(2312): require_once() #1 /home/website/public_html/wp-content/object-cache.php(587): WP_Object_Cache->delete_offending_files() #2 /home/website/public_html/wp-content/object-cache.php(433): WP_Object_Cache->open_connection() #3 /home/website/public_html/wp-content/object-cache.php(2360): WP_Object_Cache->__construct() #4 /home/website/public_html/wp-includes/load.php(856): wp_cache_init() #5 /home/website/public_html/wp-settings.php(131): wp_start_object_cache() #6 /home/website/public_html/wp-config.php(100): require_once('/home/website...') #7 /home/website/public_html/wp-load.php(50): require_once('/home/website...') #8 /home/website/public_html/wp-admin/admin.php(34): require_once('/home/website...') #9 /home/website/public_html/wp-admin/plugins.php(10): require_once('/home/website...') #10 {main} thrown in /home/website/public_html/wp-admin/includes/file.php on line 16
    
    
    
    [05-Jan-2024 12:32:00 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function __() in /home/website/public_html/wp-admin/includes/file.php:16
    Stack trace:
    #0 /home/website/public_html/wp-content/object-cache.php(2312): require_once()
    #1 /home/website/public_html/wp-content/object-cache.php(587): WP_Object_Cache->delete_offending_files()
    #2 /home/website/public_html/wp-content/object-cache.php(433): WP_Object_Cache->open_connection()
    #3 /home/website/public_html/wp-content/object-cache.php(2360): WP_Object_Cache->__construct()
    #4 /home/website/public_html/wp-includes/load.php(856): wp_cache_init()
    #5 /home/website/public_html/wp-settings.php(131): wp_start_object_cache()
    #6 /home/website/public_html/wp-config.php(100): require_once('/home/website…’)
    #7 /home/website/public_html/wp-load.php(50): require_once('/home/website...')
    #8 /home/website/public_html/wp-blog-header.php(13): require_once('/home/website...')
    #9 /home/website/public_html/index.php(17): require('/home/website...')
    #10 {main}
      thrown in /home/website/public_html/wp-admin/includes/file.php on line 16
    [05-Jan-2024 12:32:04 UTC] SQLite Object Cache: 3.39.4 no igbinary: php 8.0.30: Apache: open_connection failure database is locked (5)
    
    
    

    After a month, I started experiencing the first persistent timeout. To fix, I had to delete object-cache.php and all database files created by this plugin.

    This is the log. I hope it can be useful to help you investigate. Thanks!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author OllieJones

    (@olliejones)

    Thanks for the bug report. To clarify…

    Did every page view time out until you deleted the object_cache.php dropin and the sqlite files? Deactivating the plugin deletes the same files you mentioned.

    The root cause of this problem is tricky to isolate. If php process A is making changes to the database, php process B will wait until it is finished. If it has to wait more than a certain amount of time (WP_SQLITE_OBJECT_CACHE_TIMEOUT or 5000 milliseconds) process B tries again, twice. Then it issues the timeout message. The timeout message means that process A was somehow stuck and did not complete its operations. But, process B cannot tell what process A was trying to do.

    This situation where process B must wait for process A to finish its changes is inherent to SQLite. Memcached and redis don’t have this problem, so some sites may do better with one of those caches.

    Thread Starter wabetainfo

    (@wabetainfo)

    Hi,

    Thank you for your interest. I experienced the timeout issue for each page until I decided to delete those files. I had to delete them manually because I couldn’t deactivate the plugin from the admin panel, as I experienced the timeout there as well.

    In the past, I frequently faced timeout issues, some quite significant, which I resolved with the 1.3.7 update and moving the database to a local path and setting the timeout variable.

    I completely understand the situation and acknowledge that isolating such a problem can be complicated, but is it possible to explore any workarounds? For instance, when the database is busy with another PHP process, a direct query could be made to the Maria database until the plugin-generated database is available again. This could be an optional feature that users can activate if they encounter similar issues. I understand this might be drastic, but it could potentially resolve these timeout problems. What do you think about? Or can you study any other workarounds, please? Your plugin is very useful and important, I would love to keep using it…

    Plugin Author OllieJones

    (@olliejones)

    Would you be willing to upload a description of your site? You can get this by going to Tools -> Site Health -> Info and clicking “Copy site info to clipboard”.

    If you open up an issue in the plugin’s Github repo and paste in that info, it will help me understand what is happening on your site.

    https://github.com/OllieJones/sqlite-object-cache/issues/new/choose

    Thanks for your help and your patience!

    Thread Starter wabetainfo

    (@wabetainfo)

    Done, thanks!

    Plugin Author OllieJones

    (@olliejones)

    This is, I believe, resolved for now. https://github.com/OllieJones/sqlite-object-cache/issues/39

    Please don’t hesitate to open another topic if you have more trouble.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Timeout is back’ is closed to new replies.