Yes we would need to iterate through the map while putting/getting the ServiceSchemaInfo. Do you think we should instead choose to retain the schemaCacheMap, but make the value always a weak object. (Putting a WeakReference of the ServiceSchemaInfo in the map). This way also we can solve the current problem. What do you say?
On Sun, Jun 1, 2008 at 7:19 AM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > Hmmm.... good sleuthing. > > You definitely don't want to unregister it on endpoint stop or when done > with the client. The whole point of the cache is to hold onto it so it's > reusable. On popular thing to do is create a client, use it once, discard. > Create another client, use it once, discard. Etc... The cache is to help > that. > > I think what might make some sense is to get rid of the schemaCacheMap > entirely. Change the definitionsMap to be a Map<Object, DefPair> map where > DepPair holds a wsdldef and the schema. Thus, the keys would be the same > keys for the wsdl. > > The put/set's would be more expensive as you would need to iterate through > the cache to find the pair. I doubt the map would be very big though so > that may be acceptable. > > Dan > > > > > On May 31, 2008, at 4:55 PM, Bharath Ganesh wrote: > > I figured out a memory leak at WSDLManagerImpl schemaCacheMap. >> The schemaCacheMap here has a weak key - WSDLDefinition and value >> ServiceSchemaInfo. A key,value pair is inserted into this map while >> building >> a service. The entry is never explicitly removed from this map. Since the >> map is a WeakHashMap, it is assumed that when the key WSDLDefinition is >> weakly referenced, the entry would be removed from the map. But it is seen >> that the value ServiceSchemaInfo(the value) holds on to a SchemaInfo which >> in turn holds on to the ServiceInfo, which holds the WSDLDefinition >> through >> the AbstractPropertiesHolder. >> This would mean that the value of the CacheMap always strongly refers to >> the >> key, which would mean the entry would never be removed from the map. >> "*The value objects in a WeakHashMap are held by ordinary strong >> references. >> Thus care should be taken to ensure that value objects do not strongly >> refer >> to their own keys, either directly or indirectly, since that will prevent >> the keys from being discarded" >> >> *This would mean ServiceInfo, OperationInfo, BindingInfo, WSDLDefinition >> would all stay in the VM even after the endpoint is stopped. >> >> One solution I could think of was to explicitly remove the entry on >> endpoint >> stop, instead of relying on the WeakHashMap semantics. This would work >> fine >> for server endpoints. But Is there any way to do so for client endpoints? >> > > --- > Daniel Kulp > [EMAIL PROTECTED] > http://www.dankulp.com/blog > > > > >
