click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Herok (JIRA)" <>
Subject [jira] [Commented] (CLK-776) Starting click is very slow, if the application has a really large number of files
Date Wed, 20 Jul 2011 12:33:57 GMT


Thomas Herok commented on CLK-776:


sadly, the 2.5 million files are not static. They are/were generated by the application and
the number is increasing slowly on daily base. 

The click.xml is not used in this case. The method getTemplateFiles() in the XmlConfigService
class takes a peak at every file in the web application and is called in the loadPages method.
No configuration changes this behavior. Even if automapping is set to "false", getTemplateFiles()
is called.

Best regards
Thomas Herok

> Starting click is very slow, if the application has a really large number of files
> ----------------------------------------------------------------------------------
>                 Key: CLK-776
>                 URL:
>             Project: Click
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.3.0
>         Environment: Suse SLES 10.3 with XFS filesystem
> Tomcat 6
>            Reporter: Thomas Herok
>            Priority: Minor
>              Labels: patch
>         Attachments: LargeContextPatch.patch
> Hi,
> We have a problem with the start-up of the Click framework. Our tomcats take up to 15
minutes to start it. 
> The web application has around 2.5 million small files in a XFS file system (ouch).
> During the resolution of the list of templates within the web application Click will
traverse all the directories and files and this really takes some time. 
> So, we patched the XmlConfigService and it will only look into one configured folder.
This speeds up our starts significantly. The folder is configured as init parameter in the
> It would be great, if this patch would be in the next release. 
> Attached you will find the patch.
> Best regards
> Thomas Herok

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message