[CONTROLLER-1879] OOM due to huge RangeSet of purgedTransactions in FrontendHistoryMetadataBuilder Created: 24/Dec/18 Updated: 09/Nov/21 Resolved: 23/May/19 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | clustering |
| Affects Version/s: | Fluorine SR1 |
| Fix Version/s: | Sodium, Fluorine SR3, Neon SR2 |
| Type: | Bug | Priority: | Highest |
| Reporter: | Huafei Zhang | Assignee: | Tomas Cere |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Description |
|
Submitting a great mount of ReadOnlyTransaction and WritingTransaction in turns causes OOM. We think it is the transaction id of ReadOnlyTransaction that splits the purged transaction range into lots of segments. |
| Comments |
| Comment by Robert Varga [ 24/Dec/18 ] |
|
This is a controller issue, if confirmed. What are the steps to reproduce? Are you sure those ReadOnlyTransactions are being closed? |
| Comment by Huafei Zhang [ 26/Dec/18 ] |
|
Yes, ReaOnlyTransaction is explicitly closed.
We have wrote a endless loop structure to reproduce this issue. in each loop, we create a ReadOnlyTransaction and WriteTransaction to read and write the same network-topology node. in not a very long time , the 2G memory runs out.
|
| Comment by Robert Varga [ 07/May/19 ] |
|
There are two issues here:
|
| Comment by Robert Varga [ 07/May/19 ] |
|
https://git.opendaylight.org/gerrit/81939 deals with the first case. |