Closed lfcnassif closed 4 months ago
The user reported commit above fixed this OOME issue, so I'll merge it into master soon.
@lfcnassif, while checking an issue related to the HTML generated by UFEDChatParser (reported by another user to @felipecampanini), I observed a different behavior comparing master and 4.1.5.
Analyzing the situation, I think I found a small bug in your fix that can generate an infinite loop in for (IItemReader subitem = subItems.next(); subItems.hasNext();)
, as subItems.next()
is executed only once, right?
Clarifying: an infinite loop, if more than one item was found, and a lost message, if a single item was returned by the query, as hasNext() will return false after the next().
Thank you @wladimirleite and sorry for my fault! subitem = subItems.next();
should be also put after the last semicolon in the for clause. But your solution is much better!
An user reported OOME with a 80GB heap. Analyzing a smaller 32GB heap I asked for, there are many parsing threads using up to 1GB each:![image](https://github.com/sepinf-inc/IPED/assets/7276994/08a6b168-2efa-463a-b0ec-c49812e965bb)
Taking a look at them, most heap is being used by large![image](https://github.com/sepinf-inc/IPED/assets/7276994/33019656-f799-4539-81c2-e370413740d9)
ArrayList<Item>
objects:It took me a while to find from where those large Item lists come from. Looking those Threads stacktrace, those Lists are returned by
ItemSearcher.search(query)
calls fromUFEDChatParser
:Maybe there is some problem with the query, but it would be better to use the safer
ItemSearcher.searchIterable(query)
instead ofItemSearcher.search(query)
where possible, which returns an Iterable instead of an ArrayList.