Skip to main content

​
Identify the Performance Bottleneck

Slow loading can stem from different causes. Use this decision matrix to narrow down the issue:
  • Page loads slowly? — Check browser console for errors
    • UnresolvableObjectException? — Step 1: Fix unresolvable work items
    • No errors, just slow? — Step 2: Check dataset size
    • Timeout errors? — Step 3: Optimize queries
    • First load slow, subsequent fast? — Step 4: Server caching
Repeated UnresolvableObjectException errors during GridItems API calls severely degrade performance. Each exception creates an expensive stack trace that blocks page rendering. These errors indicate work items referenced in your RISKSHEET that no longer exist, are in the wrong project, or are unreadable to the current user.

​
Step 1: Diagnose Unresolvable Work Item References

Unresolvable work items are the most common cause of severe performance degradation.

​
Check Polarion Logs

  1. Access Polarion server logs (typically in /opt/polarion/data/logs/)
  2. Search for UnresolvableObjectException entries
  3. Identify the work item IDs mentioned in error messages
  4. Note the frequency - repeated exceptions for the same item compound performance issues

​
Verify Work Item Accessibility

For each unresolvable work item ID found in logs:
  1. Open Polarion and navigate to the work item directly: <polarion>/polarion/#/project/<PROJECT>/workitem?id=<ID>
  2. Check if the item exists:
    • Does not exist: The item was deleted - remove references from your RISKSHEET configuration
    • Exists but access denied: User lacks read permissions - adjust Polarion permissions or filter the item from queries
    • Exists in different project: Item was moved - update project references in configuration

​
Remove Unresolvable References

If work items no longer exist or should not appear:
  1. Open the RISKSHEET Configuration Editor
  2. Review column configurations with type: "itemLink", type: "taskLink", or type: "multiItemLink"
  3. Check if these columns reference unresolvable items through:
    • Custom queries in dataTypes.master.query or dataTypes.task.query
    • Hardcoded work item references in typeProperties
  4. Update queries to exclude deleted/inaccessible items:
// Example: Exclude deleted work items from query
"dataTypes": {
  "master": {
    "query": "type:risk AND NOT id:(PROJ-123 PROJ-456)",  // Exclude known deleted items
    "types": "risk"
  }
}
Before modifying queries, use Polarion’s advanced search to verify which work items actually exist and are accessible: Navigation → Work Items → Advanced Search. Copy the working query syntax to your RISKSHEET configuration.

​
Step 2: Optimize Large Datasets

If no unresolvable items exist but the page still loads slowly:

​
Check Work Item Count

  1. Open the RISKSHEET document
  2. Wait for full load (even if slow)
  3. Note the total number of rows displayed
  4. If exceeding 1,000 items, consider splitting into multiple documents or adding filters

​
Apply Query Filters

Reduce dataset size by filtering in the query: 
// Example: Filter to active items only
"dataTypes": {
  "master": {
    "query": "type:risk AND status:(open inProgress) AND created:[NOW-90DAYS TO NOW]",
    "types": "risk"
  }
}
Common filter patterns:
  • Time-based: created:[NOW-90DAYS TO NOW] (last 90 days)
  • Status-based: status:(open inProgress) (exclude closed items)
  • Project-based: project.id:MYPROJECT (specific project only)
  • Custom field: customField.priority:high (high priority only)

​
Reduce Column Count

Each column adds processing overhead:
  1. Review your column configuration
  2. Identify columns rarely used or purely informational
  3. Remove or hide them using visible: false
  4. Particularly expensive column types:
    • serverRender (requires server-side rendering)
    • calculated with complex formulas
    • multiItemLink with many linked items

​
Step 3: Optimize Query Configuration

Inefficient queries slow down data loading.

​
Simplify Custom Queries

Avoid overly complex Lucene queries: Inefficient (slow): 
"query": "type:risk AND (description:*critical* OR title:*urgent* OR customField.notes:*important*)"
Efficient (fast): 
"query": "type:risk AND customField.priority:critical"

​
Avoid Wildcard Searches

Wildcard queries (*term*) are expensive:
  • Slow: description:*keyword*
  • Fast: description:keyword (prefix match)
  • Faster: Use indexed custom fields instead of full-text search

​
Use Indexed Fields

Queries on indexed fields perform better:
  • Indexed (fast): status, type, id, project, most custom enums
  • Not indexed (slow): description, rich text fields, unstructured text

​
Step 4: Enable Server-Side Caching

If first load is slow but subsequent loads are fast, caching is working. If all loads are slow:
  1. Verify Polarion server has adequate memory allocated
  2. Check Polarion’s cache settings in /opt/polarion/polarion/configuration/cache.properties
  3. Increase cache size for work item queries if memory allows
RISKSHEET performs sorting, filtering, and pagination on the client after initial data load. Once data is loaded, interactions should be instant. If client-side operations are slow, check browser performance and disable browser extensions.

​
Step 5: Check Network Latency

Slow network connections affect load times:
  1. Open browser Developer Tools: F12
  2. Navigate to Network tab
  3. Reload the RISKSHEET page
  4. Check the time taken for /api/GridItems requests
  5. If over 5 seconds, investigate:
    • Server performance (CPU, memory, disk I/O)
    • Network bandwidth between client and server
    • Polarion database performance

​
Step 6: Monitor Sorting Performance

Custom sorting can slow down large grids:

​
Work Item ID Sorting

Work item IDs (e.g., PROJECT-123) use custom alphanumeric sorting:
  • Applied automatically to columns with binding: "id" or type: "itemLink"
  • Ensures PROJECT-2 sorts before PROJECT-10
  • Generally fast, but expensive for 5,000+ items

​
Outline Number Sorting

Hierarchical outline numbers (e.g., 1.2.3) use specialized sorting:
  • Applied to columns with binding: "outlineNumber"
  • Maintains document structure: 1.2 before 1.10
  • Can be slow with deep hierarchies (10+ levels)
Columns displaying multiple linked items sort by concatenated labels:
  • Most expensive sort operation
  • Consider hiding or making read-only if performance is critical
  • Uses JSON parsing and string concatenation

​
Verification

After optimization, you should see:
  • RISKSHEET loads in under 5 seconds for typical datasets (under 500 items)
  • No UnresolvableObjectException errors in Polarion logs
  • Browser console shows no JavaScript errors during load
  • Subsequent interactions (sorting, filtering) respond instantly
  • /api/GridItems network requests complete in under 3 seconds

​
See Also

Support TicketsSource Code
  • RiskItemsODataCollectionView.ts
  • CompareToCommand.ts