ext-solr icon indicating copy to clipboard operation
ext-solr copied to clipboard

[BUG] Memory leak/deadlock on missing PAGE object

Open saitho opened this issue 3 years ago • 2 comments

Describe the bug This is a special case that regularly occurs during our local development. We regularly switch between different websites, resulting in a missing PAGE object until Composer and Database are synced. When this happens and Solr indexer runs via cronjob, the task will use up all available RAM.

Looking into this, it happens when a language in site configuration does not have a root page translation; and a 404 handler is defined. So it's some sort of edge case here, but it still should not happen.

To Reproduce Steps to reproduce the behavior:

  1. Clear page object in TypoScript setup: page >
  2. Add a new language in site configuration but no root page translation in backend
  3. Add a 404 error handler
errorHandling:
  -
    errorCode: '404'
    errorHandler: Page
    errorContentSource: 't3://page?uid=84'
  1. Watch your RAM usage and run the indexer command (or queue initialize command from Ext:solrconsole).
  2. The php process' RAM usage increases until it reaches 100%. This may make a system unusable until the process finishes or is killed automatically.

Expected behavior The expected behaviour is that missing page object in frontend does not increase the RAM usage unnecessarily.

Used versions:

  • TYPO3 Version: 11.5.8
  • EXT:solr Version: 11.5.0-rc-2
  • Used Apache Solr Version: 8.11.1
  • PHP Version: 7.4.29
  • MySQL Version: MariaDB v10.4.24

saitho avatar Jul 04 '22 08:07 saitho

@saitho I deactivated currently EXT:solr on solr-ddev-site. The frontend gets time-outs:

Please see if TYPO3 Core has some issues with deadlock in 404 Handlings, if none create a issue for core.

Error handler could not fetch error page "https://solr-ddev-site.ddev.site/ru/404", reason: cURL error 28: Operation timed out after 30001 milliseconds with 0 bytes received (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://solr-ddev-site.ddev.site/ru/404

IMHO: That shouldn't be fixed in that way. The check should be done before trying initializing of TSFE and setting it to null in cache probably on this place:

https://github.com/TYPO3-Solr/ext-solr/blob/3ea33b4f8387f77d4a34670d0aa7bf02bdf57054/Classes/FrontendEnvironment/Tsfe.php#L315-L325

dkd-kaehm avatar Jul 22 '22 14:07 dkd-kaehm

For instance, the fix was done in CORE See: https://github.com/typo3/typo3/commit/fc51ccbf2b. We want to test if that fix working on EXT:solr.

dkd-kaehm avatar Sep 13 '22 09:09 dkd-kaehm

Can't confirm this issue with the latest(11.5.16) TYPO3 version.

saitho avatar Oct 06 '22 13:10 saitho