Jump to content
  • Publish to server is slow

    Assigned User chicuslavic
    CategoryBug report
    ReproducibilityUnable to Reproduce
    After clicking the publish to server icon towards the upper right on the main report window, the next two steps take way too long: next step (finding the location where to publish) takes 5 minutes, and the step after that (publishing itself), 10 minutes. A Jaspersoft rep showed me the ini file (C:\Program Files\TIBCO\Jaspersoft Studio Professional-6.0.0.final\Jaspersoft Studio Professional.ini) in which to change memory settings, but I am not allowed to update the file, not even after reboot and before restarting JSS, and despite that the read-only attribute for the file is off. Is there another to remedy JSS so that these two publish steps don't take so long?

    Attachments: issueDetails.zip

    User Feedback

    Recommended Comments

    Hi, I believe this problem is related to this discussion: http://community.jaspersoft.com/questions/844459/very-slow-publishing-jasperstudio


    It really breaks our workflow, so just last week I dig deeper and found the offending code. Lines bellow are referring to code from JasperSoft Studio v. 6.0.4, which is version we use, code in 6.1 should be similar:


    In /com.jaspersoft.studio.server/src/com/jaspersoft/studio/server/publish/JrxmlPublishContributor.java, line 250:256, when publishing resource-bundles, JasperSoft Studio tries to found matching bundles for every single locales found on system:


    for (Locale l : Locale.getAvailableLocales()) {

    impBundle.publish(jrConfig, jasper,

    dapath + "_" + l.toString(), mrunit, monitor, fileset,


    if (monitor.isCanceled())




    This operation takes long time, on some systems even minutes. For every locale bundle not found exception is thrown.


    I commented these lines out, recompiled .class file and publishing is now quick as it should be.


    I'm not sure about proper solution to not break others workflows (someone may need this auto-discover function?).

    Link to comment
    Share on other sites

    I have no real solution in mind. I don't understand, why it is necessary to look for all possible locales (159 on my system), but real question is probably why each locale check takes so long. I have no experience in Java programming, I tried to check the code but found nothing suspicious.


    Now when we know what part of code is slow, I hope someone could check and find exactly what's going on? We can confirm this problem on Linux and Windows on two different computers. Scenario is same - editing report loaded directly from jasper-server and then save and publish. Report must have .properties file set, otherwise publishing is quick, because problematic locales loop mentioned before is skipped.


    If I can perform some tests or anything to help, please let me know.

    Link to comment
    Share on other sites

    This code use Jasper reports library to look for properties files, usually this files are in the report directory or root (project, or other) and in the classpath. Let's say we could look directly into this folders, but how we can search the classpath for property files? We have to iterate all locales and try if it is there. Right now I don't see how we can accelerate this.


    Link to comment
    Share on other sites

    I don't know how others use this functionality. I'm not used to Java, but if I understand you properly, you cannot just search some known locations for files, you must try to load it and let java do the magic and try to find it whenever configured, right? That is your point with classpath? If so, maybe it could be configurable - a) turn search off, b) search only in given filesystem folders (report-directory, project dir..), c) full search like now.


    - maybe it would be faster to iterate over all possible target locations and create list of .properties files and then search for each locale within this list instead of doing file-system search for each individual locale? If there is some slow part in workspace/filesystem.. search code or too many targets, it would be triggered only once.


    - if someone could reproduce this and find exactly what part of search process causing this slowdown, it would also help to find proper solution. I would gladly run some code for you if it helps.

    Link to comment
    Share on other sites

    Changed Resolution from Open to Fixed

    Changed Status from New to Resolved

    Changed Assigned User from - to @chicuslavic

    I skipped classpath search, and it should be faster, because now I get the list of files and don't have to iterate over all localesthe idea with a preference is not bad, but for simplicity we'll keep it like this, for now
    Link to comment
    Share on other sites

  • Create New...