This has not been on the server side - The value of the wsdlLocation attribute (from @WebService annotation) is passed down under to the WSDLServiceFactory, which obviously will be a literal.
On Mon, Jun 2, 2008 at 5:13 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote: > > On the client side, I specifically made sure the call to set the wsdl > location on the factories did a "location = new String(location);" type > thing to make sure the String is not an interned string. Had to do that > due to the strings being compiled directly in to the code and such. It's > quite possible that hasn't been done on the server side, but probably > should. > > It's good that you're doing this. The way the "standalone" tck works, we > don't hit these things. We have that setup to create a new Bus (and thus > new WSDLManagerImpl) for each of the deployed application. Also, everything > is deployed upfront at startup. They aren't ever undeployed/redeployed. > > Dan > > > > On Jun 2, 2008, at 4:44 AM, Bharath Ganesh wrote: > > On a related note - >> There seems to be one more interesting issue here at WSDLManagerImpl. The >> definitionsMap holds the WSDLDefinitions against a weak key, again relying >> on the WeakHashMap semantics for removal. >> >> The loadDefinition(String) method loads the WSDLDef and puts this in a map >> against a String key. But this String key, is a literal String and will be >> present in the constant pool, where garbage collection never happens. This >> would mean the key would always be referenced from the constant pool, and >> the entry would never be removed:-( >> >> We shall fix this by always putting a URL as key in this map. The only >> valid >> usage I saw was from WSDLServiceFactory. The WSDLServiceFactory, instead >> of >> using the wsdlManager.getDefinition(String) method, can create a URL from >> this String, strongly refer the URL from wsdlURL field, and invoke the >> wsdlManager.getDefinition(URL) method. >> >> Any suggestions? >> >> >> On Sun, Jun 1, 2008 at 2:25 AM, Bharath Ganesh <[EMAIL PROTECTED]> >> 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 > > > > >
