You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Jarek Gawor (JIRA)" <ji...@apache.org> on 2007/07/25 00:00:31 UTC
[jira] Created: (AXIS2-3011) ServiceDescription caching leads to
memory leak
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
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jeff Barrett (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515335 ]
Jarek Gawor commented on AXIS2-3011:
------------------------------------
I added a disabled test case (DescriptionFactoryImplTests.java) in the metadata/ module to demonstrate this problem.
> 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
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515699 ]
Lin Sun commented on AXIS2-3011:
--------------------------------
Looks like the message "Two services cannot have same name." happens when the code tries to add a service which has already being added to the axisconfig. This error didn't happen before since we didn't cache the axisconfig and create a new one every single time.
One possible fix is when the axisserv name is set, use a unique value (in line 944 of EndpointDescriptionImpl.java). From the exception, the this.hashCode() doesn't seem to be generating a unique value.
> 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
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516078 ]
Lin Sun commented on AXIS2-3011:
--------------------------------
I've ran my test over an hour not hitting the Two services cannot have same name now, with a recent change in geronimo that would cache the service client. So we can ignore that error now.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515816 ]
Lin Sun commented on AXIS2-3011:
--------------------------------
Hi Dustin,
I am caching the configurationContext object. Code is same as Jarek but doing that in geronimo (by extends the ClientConfigurationFactory). We thought of doing that because we were not sure if this change will be accepted in axis2. But with that, I am running this "Two services cannot have same name." I am thinking of the changes below in line 944 of EndpointDescriptionImpl.java
- axisSvc.setName(axisSvc.getName() + this.hashCode());
+ axisSvc.setName(axisSvc.getName() + this.hashCode() + System.currentTimeMillis());
But I am not sure if that will introduce any other probs?
Lin
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515780 ]
Dustin Amrhein commented on AXIS2-3011:
---------------------------------------
Just a follow-up to explain my comments above....
Suppose in a single appserver Module A, Module B, Module C, and Module D are all deployed.
Module A and Module B both have a service client that refers to a service (say {http://example}MyService)
Module C and Module D both contain different versions of MyService. Module A points to the service in
Module C and Module B points to the same service in Module D. It seems that sharing a ConfigurationContext
between the clients in Module A and Module B could be harmful. What do you think?
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Closed: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Ann Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ann Robinson closed AXIS2-3011.
-------------------------------
Resolution: Fixed
This problem has been resolved through some other changes, including Jarek's changes committed in axis2 rev 560086.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Ann Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ann Robinson resolved AXIS2-3011.
---------------------------------
Resolution: Fixed
> 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-a.patch, 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515763 ]
Jarek Gawor commented on AXIS2-3011:
------------------------------------
Dustin,
I'm not sure about it either but this is about caching *client* configuration context only. Which means all clients (and in any app) would use the same configuration but the web services would have their own unshared configuration. Now, if the client configuration must not be shared or should not be shared then the ClientConfigurationFactory needs to be changed to do some kind of scoping like you mentioned - maybe based on the context class loader?.
Bottom line is we need to know if it is safe to share the client configuration context between all applications. If it is, then this patch should be ok. If it is not, I can write another patch/factory that does caching based on the context class loader.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Ann Robinson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ann Robinson reassigned AXIS2-3011:
-----------------------------------
Assignee: Ann Robinson
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516451 ]
Dustin Amrhein commented on AXIS2-3011:
---------------------------------------
Jarek,
I agree with some of your observations above, but I have a few comments/questions
With respect to #2: One observation, if you attempt to remove ServiceDescription from the cache you must be careful that there no outstanding requests utilizing this metadata. This will result in some strange situations depending on what you do to that ServiceDescription reference when you remove it from the cache.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jarek Gawor updated AXIS2-3011:
-------------------------------
Attachment: AXIS2-3011.patch
This is a proposed fix for one of the issue in this bug. It changes the ClientConfigurationFactory to cache the ConfigurationContext instead of re-reading the config each time.
> 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
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515749 ]
Dustin Amrhein commented on AXIS2-3011:
---------------------------------------
Lin,
Are you caching the AxisConfiguration object or the ConfigurationContext object? Is this done in your own version of a ClientConfigurationFactory? Do you have a code snippet or can you point me at the source?
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516803 ]
Jarek Gawor commented on AXIS2-3011:
------------------------------------
I applied the second patch (with updated comments) to trunk: Committed revision 561482 and 1_3 branch: Committed revision 561552.
> 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-a.patch, 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515817 ]
Jarek Gawor commented on AXIS2-3011:
------------------------------------
It all depends what the configuration context is used for or what information is stored in it. If it contains general info such as what transport driver should be used, it should be totally fine to reuse. But if some information about a particular web service is stored in it then it cannot be shared. And if it cannot be shared (since each web service client will require its own configuration context) then the ServiceDescription caching done in DescriptionFactoryImpl must be completely removed.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Lin Sun (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515513 ]
Lin Sun commented on AXIS2-3011:
--------------------------------
I've been running with a similar set of code (with geronimo has its own Axis2ClientConfigurationFactory) but the code is pretty much the same to reuse the ConfigurationContext. I am getting the stack trace below during a 10 user load test of the jaxws-calculator example (http://svn.apache.org/viewvc/geronimo/samples/trunk/samples/jaxws-calculator/jaxws-calculator-war/)
javax.xml.ws.WebServiceException: The ServiceClient cannot be created.
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(Exc
eptionFactory.java:172)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(Excep
tionFactory.java:69)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.getSe
rviceClient(EndpointDescriptionImpl.java:949)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.<init
>(EndpointDescriptionImpl.java:222)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.<init
>(EndpointDescriptionImpl.java:180)
at org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.update
EndpointDescription(ServiceDescriptionImpl.java:289)
at org.apache.axis2.jaxws.description.impl.DescriptionFactoryImpl.update
Endpoint(DescriptionFactoryImpl.java:220)
at org.apache.axis2.jaxws.description.DescriptionFactory.updateEndpoint(
DescriptionFactory.java:96)
at org.apache.axis2.jaxws.spi.ServiceDelegate.getPort(ServiceDelegate.ja
va:233)
at org.apache.axis2.jaxws.spi.ServiceDelegate.getPort(ServiceDelegate.ja
va:209)
at javax.xml.ws.Service.getPort(Service.java:44)
at org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$37c
731e2_2.CGLIB$getPort$1(<generated>)
at org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$37c
731e2_2$$FastClassByCGLIB$$1c5fd0ac.invoke(<generated>)
at net.sf.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:167)
at org.apache.geronimo.jaxws.client.PortMethodInterceptor.intercept(Port
MethodInterceptor.java:50)
at org.apache.geronimo.axis2.client.Axis2PortMethodInterceptor.intercept
(Axis2PortMethodInterceptor.java:42)
at org.apache.geronimo.jaxws.client.GenericService$$EnhancerByCGLIB$$37c
731e2_2.getPort(<generated>)
at org.apache.jsp.addResult_jsp._jspService(addResult_jsp.java:91)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:388)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
20)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:175)
at org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu
bjectValve.java:56)
at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.
invoke(GeronimoStandardContext.java:351)
at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero
nimoBeforeAfterValve.java:47)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:104)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:109)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
563)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
a:261)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ss(Http11Protocol.java:581)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:44
7)
at java.lang.Thread.run(Thread.java:801)
Caused by: org.apache.axis2.AxisFault: Two services cannot have same name. A se
rvice with the Calculator.CalculatorPort1579572774 name already exists in the sy
stem.
at org.apache.axis2.client.ServiceClient.configureServiceClient(ServiceC
lient.java:172)
at org.apache.axis2.client.ServiceClient.<init>(ServiceClient.java:139)
at org.apache.axis2.jaxws.description.impl.EndpointDescriptionImpl.getSe
rviceClient(EndpointDescriptionImpl.java:946)
... 37 more
> 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
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515738 ]
Dustin Amrhein commented on AXIS2-3011:
---------------------------------------
Jarek,
With regards to the attached patch. Is it suitable to always return the same ConfigurationContext with no scoping attached to the caching? For example, if this code is running within an app server process and there are multiple J2EE modules that have services with the exact same name, could returning the same ConfigurationContext cause a problem? I'm not sure of the answer just wanted to pose the question.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Reopened: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jarek Gawor reopened AXIS2-3011:
--------------------------------
The changes I committed were related to the affected code but they only make things slightly more efficient by creating less configuration contexts.
I'm re-opening this bug because I believe the original issue I described here still stands for the following reasons:
1) If somebody downloads Axis2 and writes a standalone JAX-WS client, he/she will find out that after a few (hundred) calls, the client will run out of memory. So I think this needs to be changed somehow, e.g. to disable caching, reuse some configuration, etc.
2) The original issue of clearing the cache was not addressed. Once a ServiceDescription gets cached, it will always live there in the cache. There should be some functions defined that can clear the entire cache or a part of the cache based on the configuration context instance, etc. For example, in an app server, once a module is unloaded I would like to remove all cached ServiceDescriptions associated with that module. Or when wsdl file for the service is changed, I would like the cached ServiceDescritpion to re-initialize.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Jarek Gawor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jarek Gawor updated AXIS2-3011:
-------------------------------
Attachment: AXIS2-3011-a.patch
The new patch just adds a couple of functions to clear the ServiceDescription cache. I'm planning to call the clearServiceDescriptionCache(ConfigurationContext) function when a module is deactivated or uninstalled (each module has its own ConfigurationContext).
> 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-a.patch, 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-3011) ServiceDescription caching leads to
memory leak
Posted by "Dustin Amrhein (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515777 ]
Dustin Amrhein commented on AXIS2-3011:
---------------------------------------
Jarek,
Suppose there are multiple J2EE modules deployed on an app server that contain numerous web service clients. If some of the clients in different modules refer to the same qualified service name, but they are actually different service implementations in separate modules, then sharing a ConfigurationContext may be undesirable. I am not sure what caching based on the context class loader would buy us in this situation. What am I missing?
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org