Uploaded image for project: 'Nuxeo Platform'
  1. Nuxeo Platform
  2. NXP-27958

Reduce excessive response size of Spreadsheet editor's search request

    XMLWordPrintable

    Details

    • Release Notes Summary:
      Loading Spreadsheet editor is more efficient thanks to reduced response size.
    • Backlog priority:
      800
    • Sprint:
      nxsupport 11.1.4, nxsupport 11.1.5

      Description

      In some particular cases, the HTTP request, sent by the spreadsheet editor to retrieve the documents to display, times out (305 seconds).
      This is due to the fact that too much unnecessary information are requested.

      The following use case is very problematic, and a customer is experiencing the issue:

      • document type DocA has a multi-valued Document property named links:docBs, which stores documents of type DocB
      • document type DocB has a multi-valued Document property named links:docAs, which stores documents of type DocA
      • create 1 document of type DocB
      • create 2,000 documents and for each one of them, add the DocB created above to their property links:docBs
      • add the 2,000 DocA document to property links:docAs of the DocB document
      • go to a search that lists all the DocA documents, switch to the list or table view and open the spreadsheet editor

      Expected result: the spreadsheet editor opens with the first page of result.
      Actual result: the spreadsheet editor opens but never display any rows (times out after 305 seconds)

      It times out because it takes too long to generate the response, because of the recursive resolution of documents from properties links:docBs and links:docAs, due to HTTP header depth: max.

      Here are the HTTP request provided to the search request:

      • X-NXDocumentProperties: *
      • fetch-document: properties,versionLabel
      • depth: max
      • others:
        • Nuxeo-Transaction-Timeout: 305
        • enrichers-document: permissions,thumbnail
      • fetch-directoryEntry: parent
      • translate-directoryEntry: label

      Because of the depth: max HTTP header, we encounter a bad situation where the search returns a DocA document linked to the one DocB (which is linked to the 2,000 DocA):
      1. its links:docBs property is marshalled, rendering the one DocB document with all its properties
      2. and the DocB documents has 2,000 DocA documents in its links:docAs property, which are rendered with all their properties
      3. each of the 2,000 DocA documents get marshalled also, including their links:docBs property, go back to point 1 for an almost infinite loop.

      A possible solution is to change the HTTP header depth: max to depth: root. But this is hard-coded in spreadsheet editor's code. It should be possible to configure the HTTP headers.
      Now, I am not totally sure that depth: root would return enough information for the properties of type Document and multi-valued Document.

      Moreover, I don't even see the goal of using depth: max, depth: children would be enough most of the time, but I think it would be returning too much in this particular case.

      Also, enricher permissions seems useless for the spreadsheet editor.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 hour, 15 minutes
                  1h 15m

                    PagerDuty

                    Error rendering 'com.pagerduty.jira-server-plugin:PagerDuty'. Please contact your Jira administrators.