| David Boreham (JIRA) 2005-06-06, 7:47 am |
| [ http://issues.apache.org/jira/brows...ts#action_65716 ]
David Boreham commented on DIRMINA-41:
--------------------------------------
Yeah, I thought of that as a fix. However...what made me pause
was the fact that in invesigating the leaks Elliot instrumented
the allocs and releases, and we looked at the resulting counters.
In the case we were checking (searching for users), something
like 90% of the buffer allocations were of the wrapped type.
So I was thinking if we disable pooling for those buffers then
what value is the pooling mechanism ?
If it were known that we could re-cycle nio buffers that were
originally made with a wrap() call, then all would be well:
just try to get them from the pool first.
However, reading the Sun doc I wasn't confident that the internal
behavior is well understood. E.g. for the clear() method they
say something like : this is a bit like cleaning out the object
but not quite (nothing like knowing exactly what your code
does, eh ?!).
> Memory Leaks
> ------------
>
> Key: DIRMINA-41
> URL: http://issues.apache.org/jira/browse/DIRMINA-41
> Project: Directory MINA
> Type: Bug
> Versions: 0.7
> Reporter: elliot schlegelmilch
> Assignee: Trustin Lee
> Fix For: 0.7.1
> Attachments: bytebuffer.patch
>
> Discovered by adding 10,000 users and searching repeatedly. Ran in profiler and compared mid search to post search to find many objects aren't getting gc'd.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|