TYPO3 Core

Related to #17210

That sounds very interesting! I will investigate this...

Hm, maybe this could also be related to bugs #17053 and/or #17053 - without having had a deeper look until now.

same problem. slowdown and huge cache_hash with a lot of MENUDATA.
but we do not use TMENU_LAYERS

our menu looks like

wrapItemAndSub = bla1 || bla2 || bla3 || bla4 || bla5
allWrap.stdWrap {
prepend = IMG_RESOURCE
prepend {
stdWrap.wrap = style="background-image: url(|)">
file = GIFBUILDER
......

and yes we have heavy traffic on FE

Same problem on 4.0 and after upgrade to 4.1.5 with GMENU and GEMNU-Layer. cash_hash table gets filled up with MENUDATA (about 95% of all entries).

Have checked it on other systems as well.
Another one on 4.02 with TMENU-Layers seems to have the problem as well as one on 4.1.5 with TMENU only.

Is this still a problem?

If so, could someone please submit a ready to use TS MENU to reproduce this? The above TMENU_LAYERS example does not work for me at all. (i just changed the special.value part) and moved to page.10 = HMENU.

I can recognize the completely same problem on a TYPO3 4.2.1, php5, mysql5 with tmenu_layers.
But the interesting thing is, that this only happens to one TYPO3 page, where the others (which are all sharing one global source) have a reasonable size of cache_hash.
Also the traffic can't be the reason, as there are more pages which have similar traffic (~1k uniques a day).

cache_ tables are innodb here.

I got the same problem with Typo3 4.2.6, but I'm not using TMENU_LAYERS.
Just some ordonary TMENUs. I can't reproduce the Problem.
Is there still no solution ?

Please check if it still happens with the latest version. TYPO3 4.2.6 is pretty old nowadays...

Hi Michael, I can confirm this bug is still current with TYPO3 4.2.10

After only about 15 hours (since the last truncation of the cache_hash table) of a small-ish site with a small handful of visitors per minute, the cache_hash table has grown to 1.8G. I can't imagine what this problem would be like for a large site.

Anyway, here is what the cache_hash entries look like for the site I'm referring to: http://www.users.on.net/~carey/MENUDATA.html , does that give anyone any clues as to what might be causing these entries? (In case this helps anyone: to get that result in phpmyadmin I added a htmlspecialchars() for a $blobtext variable and placed a display_blob=true in the phpmyadmin source).

I'm not sure what sort of menus or whatnot this site has configured in TYPO3, so I'm not sure what is causing this bug. I'm primarily just coming from a sysadmin perspective, and from this perspective it's definitely a problem! :-)

Is there any other info I can provide?

It would be great to know which type of menu is used.

Anyway I can confirm this bug on 4.2.10 too.

I worked around by configuring innodb to be limited to smaller filesize.
But I think this is not the best way at the long last. ;)

I now have about 300MB cache_hash with about 400MB cache_page on a website with about 1k uniques a day (what is really not that much).
Big enough for basically caching some text IMO ...

I have not checked this on 4.3, but I think it will happen during January.

Hey guys, we're encountering the very same problem for ages now. Isn't there any solution to this yet? This slows down our whole system and we're forced to implement cronjobs to clear the cache table on a regular basis. It would be great if you could raise the priority on this.

I can confirm this is still a problem on TYPO3 4.4. I am happy to provide whatever info is needed. I just don't know what other info to provide, so please let me know.

Note that this bug could be classed as a security problem, sites could be Denial of Serviced due to this bug (database size filling disk and/or grinding to a halt).

Hi, this bug is still flooding our cache_hash tables, using the latest TYPO3 4.4, version 4.4.11. Any word on this? Cheers

With TYPO3 4.4.x the problem got 'better' (so i don't have 1,8gb cache tables on small sites any more), but it is ongoing to grow in an unreasonable size (800-900mb after some days, while table has about 100mb after truncating caching tables).
With Version 4.5.X i can't say atm, but in a few days one of the concerned installations would be upgraded to 4.5.x and then i could tell you more about this.
One of the concerned installationes will upgraded too, but with a complete redesign an complete new Typoscript etc ...
We will use there a superfish menu (based on a simple tmenu). the installation is a bigger one, with some users per day, maybe i can get some meaningful key-data i can provide here.

last but not least, the typoscript-code looks pretty much like the example code, posted initally to this topic.

cheers from tyrol,
clemens