Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.gui > #613

Re: memory allocation for

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

Show all headers | View raw


  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 | NextPrevious in thread | Find similar


Thread

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