Uploaded image for project: 'JBoss BPMS Platform'
  1. JBoss BPMS Platform
  2. RHBPMS-317

Business central long initial loading time due to not cached js files

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 6.3.0
    • 6.2.0
    • Business Central
    • None

      +++ This bug was initially created as a clone of Bug #1283304 +++

      Description of problem:
      There is rather long initial loading time for business central after logon - might not be visible too much on localhost or local network as it's rather fast but is really visible on slower networks.
      Problem is caused by disabled caching of resources (*.cache.js) while they are perfectly cacheable.

      when looking at network trace from the browser after logon you can notice hat every time around 7 MB js file is downloaded from the server while it should be downloaded only once.

      Version-Release number of selected component (if applicable):

      How reproducible:
      open network trace in the browser (like Chrome) and logon to business central - look at cache.js file being always downloaded instead of being served from cache after first use.

      Steps to Reproduce:
      1.
      2.
      3.

      Actual results:
      cache.js files are downloaded every time user logon

      Expected results:
      cache.js files should be downloaded only once

      Additional info:

      — Additional comment from Maciej Swiderski on 2015-11-18 11:36:05 EST —

      Assigning to Christian as he (and Mike) did most of the work on master:
      https://github.com/uberfire/uberfire-extensions/commit/9b91985877bdceb76a1edd79af2fc368997e4056
      https://github.com/droolsjbpm/kie-wb-distributions/commit/33415d4d38f73d233122913563c2bb3156dc14d7
      https://github.com/droolsjbpm/kie-wb-distributions/commit/5f503888b134e77307e0834397b65633636fca4b

      Christion, please double check if above commits are all that should be back ported to solve this issue.

      — Additional comment from JBoss Product and Program Management on 2015-11-18 11:40:08 EST —

      Since this issue was entered in Red Hat Bugzilla, the release flag has been
      set to ? to ensure that it is properly evaluated for this release.

      — Additional comment from Christian Sadilek on 2015-11-18 11:46:06 EST —

      Yes, that's all the commits needed.

      — Additional comment from jbride@redhat.com on 2015-11-18 14:31:14 EST —

      Thank you for identifying this!
      Turns out this actually becomes important in two use cases:

      1) on-line training: Student lab environments for RHT's BPM enablement course (OPEN and SkillsExchange) is hosted in the cloud. First impression for these students brand new to BPM Suite is the initial log into their remote biz-central web app in the cloud. We instruct them to be patient but there is still a high temptation to press the refresh button in their browser as they wait for what turns out to be a 7MB download.

      2) partners / customers who have shared BPM Suite dev / test environments in their private cloud. We are seeing more of this. Often times their private network is not great.

      Don't want to hijack this BZ but related: would be nice to have a javascript widget that shows real-time download status. Current status widget along with browser status (http://i64.tinypic.com/293bll3.jpg ) is OK but doesn't indicate how much of the download remains. Sorry, not sure if an off-the-shelf js widget that can do this even exists.

      Another related topic: are the BPMN2 process designer javascript libraries configured to automatically get cached ?

      — Additional comment from Christian Sadilek on 2015-11-18 18:41:09 EST —

      PRs sent for inclusion in 6.2:

      https://github.com/uberfire/uberfire-extensions/pull/125
      https://github.com/droolsjbpm/kie-wb-distributions/pull/141

            csa_jira Christian Sadilek (Inactive)
            rhn-support-alazarot Alessandro Lazarotti
            Juraj Soltes Juraj Soltes (Inactive)
            Juraj Soltes Juraj Soltes (Inactive)
            Alessandro Lazarotti, Alexandre Bakos, Christian Sadilek (Inactive), Jeffrey Bride, Kris Verlaenen, Lukáš Petrovický (Inactive), Maciej Swiderski (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: