Uploaded image for project: 'Service Packs and Hot Fixes'
  1. Service Packs and Hot Fixes
  2. MNT-18497

Displaying Folder With Many Linked Nodes is Slow in Share

    Details

    • Bug Priority:
      Category 2
    • Escalated By:
      CSO
    • ACT Numbers:

      00910760, 01006710

    • Premier Customer:
      Yes
    • Sprint:
      Team 6 - Sprint 1, Team APPS 1 - WD - Sprint 2
    • Story Points:
      13
    • Delivery Team:
      Feature Teams Apps

      Description

      Problem Description

      A folder with many linked nodes takes a long time to display in Share. This is because the metadata of all the linked nodes is retrieved in the JSON response. If the linked nodes have
      large custom properties, the JSON response would be huge and can have a considerable impact on the time taken to display the folder in Share. As the properties of the linked nodes
      are not displayed in Share, can the metadata retrieval be postponed till the user accesses
      the actual link ?

      Steps to Reproduce

      1) Create a folder in share called test
      2) Create another folder in share called test1
      3) Create a rule in folder test1 to add the Dublin Core Aspect to
      all items created in the folder.
      4) Create a document in folder test1
      5) Edit the Dublin Core properties to add about 1000 characters in each property.
      6) Create a link for the newly created document in folder test.
      7) Click on folder test.
      8) Using Inspect Element in Firefox, copy and paste the URL used to display the folder
      9) Note that the JSON response has all the properties of the linked node. Attached JSON response from my environment to the JIRA.

      Actual Behavior

      Metadata of the linked nodes is retrieved and display of folder is slow

      Expected Behavior

      Metadata of linked nodes is not retrieved, so that folder is displayed quickly

       

      Customer notes:

      In case there are links (app:folderlink) under some folder, the generation of that page in Share UI takes really long time. 

      I did some investigation and it is caused by Share webscript which is called for generating a list of nodes (doclist). 
      Example of the webscript URL: 
      http://<host:port>/share/service/components/documentlibrary/data/doclist/all/node/alfresco/company/home/VertexDM_many/Folder%20only?filter=path&size=50&pos=1&sortAsc=true&sortField=cm%3Aname&libraryRoot=alfresco%3A%2F%2Fcompany%2Fhome 

      If there is only 1 subfolder (cm:folder) under specific folder, the JSON response size is around 7KB - see "OneFolder.json". 

      If I have 1 link under different folder, the response is 174KB (25-times more that for 1 folder) - see "OneLink.json". 

      The problem is that doclist webscript returns also metadata of "Linked Node" and those metadata are really huge - this can be seen in JSON in following part: 
      "node": {"linkedNode": ...} 

      I am just wondering why doclist webscript returns metadata of linked node even though those properties are not displayed in Share UI. For me it looks like redundant information. Therefore, it could be skipped from doclist webscript. 

      In case we have a folder with more links (f.e. 100), Share UI will receive more that 10MB from Alfresco and it takes really long time - see "slow_response.PNG". 

      So my questions are: 
      1. Why doclist webscript returns also metadata of linked node? 
      2. Is it safe to modify doclist webscript in order to display affected folders quicker? 
      3. What is a correct webscript which should be changed? Would it be Share webscript or Alfresco webscript? Most likely Alfresco one. 

        Attachments

        1. cold_vanilla_8s.png
          cold_vanilla_8s.png
          286 kB
        2. curl_script.sh
          3 kB
        3. examplenormal.json
          29 kB
        4. examplewithlinks.json
          27 kB
        5. mylinknode.json
          10 kB

          Issue Links

            Structure

              Activity

                People

                • Assignee:
                  abalmus Alexandru Balmus
                  Reporter:
                  kprakash Kavitha Prakash [X] (Inactive)
                • Votes:
                  1 Vote for this issue
                  Watchers:
                  14 Start watching this issue

                  Dates

                  • Created:
                    Updated:

                    Structure Helper Panel