Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.gui > #613
| From | "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> |
|---|---|
| Subject | Re: memory allocation for |
| Message-ID | <45a428ab$0$5213$4c368faf@roadrunner.com> (permalink) |
| Newsgroups | comp.lang.java.gui |
| References | <envor7$ja9$1@south.jnrs.ja.net> |
| Date | 2011-04-27 15:28 +0000 |
| Organization | TDS.net |
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
Back to comp.lang.java.gui | Previous | Next — Previous in thread | Find similar
memory allocation for a m "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
Re: memory allocation for "Daniel Pitts" <daniel.pitts@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
Re: memory allocation for "Nigel Wade" <nigel.wade@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
Re: memory allocation for "Brandon McCombs" <brandon.mccombs@THRWHITE.remove-dii-this> - 2011-04-27 15:28 +0000
csiph-web