[
https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516743
]
Jeff Barrett commented on AXIS2-3011:
-------------------------------------
Hi Jarek,
Here are a few things we need to consider regarding the scoping of the cache
and freeing it up
1) There is no client API that indicates the client is done with the Service it
created. So, there's really no safe place for the ServiceDelegate and the
associated ServiceDescription hierachy to be released as far as I can tell.
Until the client "exits", it could use that Service. In an unmanaged
environment, that "exit" is the VM exit. In a managed case, that "exit" could
be the module (in J2EE terms) being stopped and unloaded; so in the managed
case, there may be an opporunity to remove the ServiceDelegate and associated
ServiceDescription hierachy. In the unmanaged case, I don't know how we could
do that.
2) The ServiceDelegate and the associated ServiceDescription hierachy is
created when the client does a Service.create(...). If a client creates a new
Service in a loop, it may run out of memory, just as it might creating other
sorts of objects. I grant that only being able to create a "few hundred" is
probably smaller than expected. Still, creating a few hundred distinct
ServiceDelegates in a client may be a bit of a corner usecase.
3) Related to (1) above, the expectation is that a managed environment will
provide its own implementation of the ClientConfigurationFactory which would
scope the Service (and thus the ConfigurationContext and ServiceDescription
hierchy), for example, to a module. The version of the
ClientConfigurationFactory in SVN is for the J2SE unmanaged client case, where
the scoping is VM-wide.
4) As Dustin noted regarding removing the ServiceDescription when the wsdl file
is changed (or for any cache cleaning), there is a timing issue that needs to
be addressed. The ServiceDescription hierachy can't be re-initialized if there
are any in-flight requests. This is particularly a problem with async
responses which haven't arrived yet. Perhaps some sort of "outstanding
response" indicator that wouldn't cleanup the Service until the response was
received might work, with logic that would throw an exception after that if the
Service was used. I'm not sure that would be spec-compliant though. And it
brings up the interesting situation of a client possibly having multiple
ServiceDelegates to a Service with different versions of the WSDL.
I think that you bring up very good points, and there is certainly room for
improvement here. There are some subtle issues that need to be considered,
though.
> ServiceDescription caching leads to memory leak
> -----------------------------------------------
>
> Key: AXIS2-3011
> URL: https://issues.apache.org/jira/browse/AXIS2-3011
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: jaxws
> Reporter: Jarek Gawor
> Assignee: Ann Robinson
> Attachments: AXIS2-3011.patch
>
>
> The DescriptionFactoryImpl.createServiceDescription() function attempts to
> cache/reuse the ServiceDescription objects and that leads to memory leaks.
> First, a Hashtable is used for the cache. That means, any ServiceDescription
> created will always live in the cache and won't ever be reclaimed (and there
> is no clear cache function). Some sort of WeakHashMap could help the problem
> so that at least some unused ServiceDescription objects could be reclaimed.
> Second, the createServiceDescription() uses the
> DescriptionFactory.createClientConfigurationFactory().getClientConfigurationContext()
> to get the client configuration context. It looks like by default the
> ClientConfigurationFactory.getClientConfigurationContext() does NOT cache the
> configuration context. Therefore, each call creates a new configuration
> object. That means, that by default ServiceDescription will NOT be reused
> since the configuration context object instance is used to determine if the
> ServiceDescription should be reused or not (see DescriptionKey.equals()
> function).
> So, a simple program that calls createServiceDescription() repeatably in a
> loop (with the same arguments) will quickly run out of memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
