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
