Item10754: Enabling Languages makes view hang forever

On 1.1.3 try to enable Languages in configure

And then view any page.

The working/languages.cache is created but empty and the perl code hangs forever.

Remember to delete old cache file before trying.

-- KennethLavrsen - 17 May 2011

It is related to the compressed .mo files. It makes the site hang. It does not work at all.

-- KennethLavrsen - 17 May 2011

If I delete the .mo files and the cache file the cache file is created and all works.

If I then reenable the compression and let configure recreate the .mo files the view hangs again.

It is simply the compression feature that does not work at all.

-- KennethLavrsen - 17 May 2011

Follow up

The issue is related to the version of CPAN libs that are installed on the server. Upgrading them cures the problem.

I do not think we should try and fix the issue so it works with buggy CPAN code. But we should find out what the lowest confirmed version of the libs we know works and define this in the MANIFEST so confugure can warn about older versions. And maybe if we could avoid hanging the system.

Can the code ignore the .mo files if the CPAN version is too old of the critical library? Or is it the CPAN lib that decides to take the .mo instead of the .po?

If so, we can perhaps block making the .mo files in configure unless the version is the required version or newer.

My CPAN updated several libs when I upgraded. Can anyone tell which is the one we can assume makes the system hang?

-- KennethLavrsen - 25 May 2011

Hi Kenneth, for reference, do you know which lib in particular? and even better, what version was causing problems, and the version you have now which works properly? Or did you just do a cpan upgrade, in which case you probably won't be sure?

I guess we need to do more testing so we can write a configure checker

-- PaulHarvey - 14 Jun 2011

We should add a configure checker, but I don't know which CPAN library to explore. So I've asked for Olivier for input

-- PaulHarvey - 18 Jun 2011

I don't know either. I know Lavr and Micha upgraded some, and it fixed it, but I couldn't reproduce the error, even with the same libraries Micha had, so...

-- OlivierRaginel - 18 Jun 2011

Can't remember what exactly fixed it for me: I did upgraded the relevant cpan libs as far as possible within the set of distributed deb packages part of the distro. However, as I did not want to have too many perl libs installed manually I went the easiest way and removed all compiled language files ... which fixes it as well. It does not make any difference for me either in a persistent perl environment (fastcgi) as language files are only loaded at the BEGINing. Improving this doesnt seem to be worth the effort, or is it? So I'd suggest to disable compiling language files again by default.

-- MichaelDaum - 09 Jul 2011

I finally took the time to dig back in the history.

It is not 100% sure what cured this because the cure meant updating a CPAN lib which again updated a few others. What I cannot say is if it was the one I upgraded or the extras.

I upgraded Locale::Maketext::Lexicon to 0.86. Before the upgrade it was 0.76.

Locale::Maketext got upgraded from 1.09 to 1.17

From the same IRC chat I can see that MichaelDaum had Locale::Maketext::Lexicon 0.77 and saw the problem.

OlivierRaginel had 1.13 for Local::Maketext and 0.82 for Locale::Maketext::Lexicon and did not have the problem.

The one we distribute with Foswiki is Locale::Maketext::Lexicon 0.79 and no Locale::Maketext itself. As far as I can tell the 0.79 is also OK.

So from this I would say that a known safe combo is

• Local::Maketext >= 1.13
• Locale::Maketext::Lexicon >= 0.79

So unless someone can get a closer match to where the problem got fixed maybe these are the versions we should put in the configure checker for 1.1.4

MichaelDaum does this make sense?

-- KennethLavrsen - 28 Aug 2011

Do you want the checker to just warn about a bad dependency? Add a minimum to each of the dependencies in the DEPENDENCIES file, or do you want to have the checker that builds the compiled files bypass the compile step?

-- GeorgeClark - 28 Aug 2011

I just recently had to disable $Foswiki::cfg{LanguageFileCompression} on my foswiki/trunk yet again, even with up-to-date perl packages. As I don't see any performance gain anyway, $Foswiki::cfg{LanguageFileCompression} should default to off in the next release. This setting is causing too much headaches in the current perl landscape unfortunately.

I'd strongly encourage everybody to do so as well, i.e. when running in a persistent perl environment (fastcgi, mod_perl).

-- MichaelDaum - 29 Aug 2011

I've changed the default to false on both trunk and release 1.1. Also updated the help text to state that it causes issues on some systems and should be considered experimental.

Any chance of debugging why/how it hangs?

-- GeorgeClark - 29 Aug 2011

I do not have a failing system any longer and it is a pain to downgrade CPAN libs. But I remember from the trace that the hanging was deep in the CPAN lib. I doubt we did something wrong in our code.

I agree with turning the feature off by default. Good enough to leave it like that for 1.1.4

-- KennethLavrsen - 05 Sep 2011

So with this disabled by default and documented as experimental, can we defer this task to 1.1.5 or ...? It's a new feature in 1.1.4, so we don't need to document this change.

-- GeorgeClark - 23 Sep 2011

Yes I am perfectly OK with that.

-- KennethLavrsen - 24 Sep 2011

I also encountered a hang and had to disable the setting, remove the mo files and delete the cache file.

My lib versions are:

• Locale::Maketext: 1.14 (not shipped with FW)
• Locale::Maketext::Lexicon: not installed, so it uses the version that ships with FW: 0.79

-- ArthurClemens - 27 Nov 2011

Setting this to closed. The feature is disabled. No need to change the default.

-- GeorgeClark - 11 Jan 2015

Commenting is disabled while not logged in