UIData: Huge memory consumption for facets containing UIInput

Primefaces: 8.0++

Description of the bug

Recently our server (WF 10) crashed with OOM exception. The heapdump revelead over 90mio instances of HashMap#Node (consuming 4GB of heap space). Nearly 90% of those instances exists because of the state saving mechanism (50% of those nodes are filled with SavedState instances).

It looks like that the facets (like filter) are stored per row-index instead of only one time.

Steps to reproduce

Reproducer: https://github.com/fanste/primefaces-test/tree/test-7369

1. Add a breakpoint to PF’s UIData, line 481
2. Open the index page
3. Each time setRowIndex is called, UIData will save it’s state, which also iterates over the facets of each column. At some point you will see, that the componentID will contain the rowIndex which makes no sense for some facets.

Effectively it will generate an entry in the hashmap for each column times each row. Imagine you have a datatable with 50 columns and 50000 rows - that was the problem in our case.

I know that it makes no sense to display that many data at once. Therefor we used a datatable with pagination=true. It seems that the user visitied each single page. Otherwise the map should not be flooded with SavedState instances of each single row.

[fanste]

it looks like that the facets (like filter) are stored per row-index instead of only one time.

Can you ellaborate? What makes you think that?

Because the state map contains the component IDs of the filter’s UIInput multiple times - including the rowIndex: f:dt:idOfFilter vs f:dt:0:idOfFilter, f:dt:1:idOfFilter, …

UIData#setRowIndex > #setRowIndexWithoutRowStatePreserved > #saveDescendantState > iterates over children (here: column) and calls overloaded #saveDescendantState > iterates over facets of that column.

Because of UIData#saveDescendantState, the ID of each visited component is resetted. Therefore it also resets the ID of the facet components which than include the rowIndex in its clientId.

Therefor we used a datatable with pagination=true.

pagination won’t change a thing. Ideally, you should use a lazy model for better perf

It should be better than using a non-paged table which always will render all rows. lazy is not possible due to some customer requirements…

(both because of isInSameGroup)

Shouldn’t be called if you’re not using grouping features

I’ve just listed all occurences in that method. Detailed example: 1157 calls setRowIndex. Maybe a header row is used, than inSameGroup in line 1159 will do it again. If inSameGroup is not used, 1164 calls setRowIndex again. It has nothing todo with the main problem it was just an additional observation and could be moved to some new optimization issue.

[melloware]

Reproducer from #925: pf-925.zip

GET the page. Initial rendering yields the expected output: there is no current row in a header, but there is a column.

2015-11-30 20:36:50,816 INFO  [stdout] (default task-47) Valid state: row null, col a
2015-11-30 20:36:50,817 INFO  [stdout] (default task-47) Valid state: row null, col a
2015-11-30 20:36:50,817 INFO  [stdout] (default task-47) Valid state: row null, col a
2015-11-30 20:36:50,820 INFO  [stdout] (default task-47) Valid state: row null, col b
2015-11-30 20:36:50,820 INFO  [stdout] (default task-47) Valid state: row null, col b
2015-11-30 20:36:50,821 INFO  [stdout] (default task-47) Valid state: row null, col b

Now press the “submit” button. Observe the output:

2015-11-30 20:36:57,629 INFO  [stdout] (default task-54) Valid state: row null, col a
2015-11-30 20:36:57,629 INFO  [stdout] (default task-54) Valid state: row null, col a
2015-11-30 20:36:57,630 INFO  [stdout] (default task-54) Valid state: row null, col b
2015-11-30 20:36:57,630 INFO  [stdout] (default task-54) Valid state: row null, col b
2015-11-30 20:36:57,631 ERROR [stderr] (default task-54) Invalid state: row 1, col null
2015-11-30 20:36:57,632 ERROR [stderr] (default task-54) Invalid state: row 1, col null
2015-11-30 20:36:57,633 ERROR [stderr] (default task-54) Invalid state: row 2, col null
2015-11-30 20:36:57,633 ERROR [stderr] (default task-54) Invalid state: row 2, col null
2015-11-30 20:36:57,636 INFO  [stdout] (default task-54) Valid state: row null, col a
2015-11-30 20:36:57,637 INFO  [stdout] (default task-54) Valid state: row null, col b
2015-11-30 20:36:57,639 ERROR [stderr] (default task-54) Invalid state: row 1, col null
2015-11-30 20:36:57,640 ERROR [stderr] (default task-54) Invalid state: row 2, col null
2015-11-30 20:36:57,643 INFO  [stdout] (default task-54) Valid state: row null, col a
2015-11-30 20:36:57,643 INFO  [stdout] (default task-54) Valid state: row null, col a
2015-11-30 20:36:57,644 INFO  [stdout] (default task-54) Valid state: row null, col b
2015-11-30 20:36:57,645 INFO  [stdout] (default task-54) Valid state: row null, col b
2015-11-30 20:36:57,646 ERROR [stderr] (default task-54) Invalid state: row 1, col null
2015-11-30 20:36:57,646 ERROR [stderr] (default task-54) Invalid state: row 1, col null
2015-11-30 20:36:57,649 ERROR [stderr] (default task-54) Invalid state: row 2, col null
2015-11-30 20:36:57,649 ERROR [stderr] (default task-54) Invalid state: row 2, col null