> There was a problem in MINA 1.1.7 in 1.5.4. In fact, if you do a big
> search request, responses are stacked into MINA until the searchResultDone
> is found. It has been fixed while moving to MINA 2.0.
> So now, in trunk if you still experience a OOM, then we should investigate
> what happens.
>
> We also fixed a memory leak somewhere else (don't remember, but Norval
> Hope found it and we applied the patch)
>
> Can you do some profiling session with Yourkit to see where the memory is
> being sucked ?
I've done some profiling with JMP and found that 1.5.1, 1.5.4 and trunk all
seem to be holding on to the SearchResponseEntryImpl objects until the end of
the search.
For ApacheDS 1.5.4 and 1.5.1 the SearchResponseEntryImpl objects owner graph
looks like:
org.apache.directory.shared.ldap.message.SearchResponseEntryImpl
owned by
org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer.message
owned by org.apache.mina.filter.executor.ExecutorFilter$Event.data
owned by java.util.LinkedList$Entry.element
owned by java.util.LinkedList$Entry.(next, previous)
In ApacheDS trunk (as of 31st March):
org.apache.directory.shared.ldap.message.SearchResponseEntryImpl
owned by org.apache.mina.core.write.DefaultWriteRequest.message
owned by
org.apache.mina.filter.codec.ProtocolCodecFilter$MessageWriteRequest.parentRequest
owned by Object[1490]
owned by org.apache.mina.util.CircularQueue.items
owned by
org.apache.mina.core.session.DefaultIoSessionDataStructureFactory$DefaultWriteRequestQueue.q
Strangely ApacheDS 1.5.4 actually streams the search responses to the client
immediately - but still keeps the SearchResponseEntryImpl objects in memory.
Any ideas are appreciated!
Thanks,
Martin
