Re: memory allocation for
To: comp.lang.java.gui
Nigel Wade wrote:
Brandon McCombs wrote:
hello,
My application makes multiple JNDI search calls to a directory server.
The search method returns a NamingEnumeration of SearchResults and I run
through a while loop that converts the enumeration to a Vector of
SearchResults. At another time I process the Vector to add the
SearchResults to a ListModel for viewing their properties.
My application takes up a lot of memory after running that search
operation a handful of times. It seems that the majority of the memory
allocation comes from the hasMoreElements() method of the enumeration
that I call within the while() mentioned above. I don't see any way of
not calling that method since I need it to grab the search results. The
question I have is why would the JVM use so much space for that method
and is there anything I can do to reclaim the memory? JProfiler says
that after a handful of search() executions there are over a million
allocations of hasMoreElements() that take up 50 megs. Jprofiler shows
garbage collections are occurring but since a method and not an Object
is taking up the memory I don't know how to fix this problem.
As a side note, if it was possible to properly cancel JNDI search
methods (from the InitialLdapContext class) then I wouldn't have such a
problem but once those searches start they can't be canceled from what I
can gather, despite utilizing threads.
thanks
Brandon
My only guess, and this is a guess, is that because you are hanging on to the
SearchResult returned by the NamingEnumerator, that whatever implemented that
NamingEnumerator isn't getting freed for garbage collection.
NamingEnumeration comes from javax.naming so I guess that makes it Sun's
fault.
Can you change your code so that the objects which are stored in the ListModel
are not the SearchResults, so that no object reference from within the
SearchResult is held onto?
not exactly. I built a parser that reads the attributes and the
attribute values from the search result class. I have to use *something*
to store the data so I chose to use the default object class for JNDI
searches.
I've changed code to create a new listmodel every time to make sure the
searchResults from the old one are gone. I'm sure this adds a bit more
overhead but it seems to help, a little.
I noticed that hasMoreElements() is from Enumeration while hasMore() is
from NamingEnumeration however if I change my code to hasMore() I get
JNDI errors for some reason. The errors are random as well: 1 time I got
an error about not following references and another time I got an error
about size limit exceeded but not sure what size limit was being referenced.
I guess I'll have to keep experimenting and may have to resort to just
increasing the JVM's memory parameters.
---
* Synchronet * The Whitehouse BBS --- whitehouse.hulds.com --- check it out free usenet!
--- Synchronet 3.15a-Win32 NewsLink 1.92
Time Warp of the Future BBS - telnet://time.synchro.net:24