[jira] Resolved: (TUSCANY-2612) Use of java.beans.Introspector leads to memory leaks in long runs

["Scott Kurz (JIRA)" <de...@tuscany.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-2612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Kurz resolved TUSCANY-2612.
---------------------------------

    Resolution: Fixed

There must have been a different explanation for the problem I saw.  No point leaving this open then.  If I can identify a clear issue I'll open a new JIRA.

> Use of java.beans.Introspector leads to memory leaks in long runs
> -----------------------------------------------------------------
>
>                 Key: TUSCANY-2612
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2612
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> Since the java.beans.Introspector caches the classes it introspects, we can have memory leaks if we don't flush these classes from its cache.
> Use of the Introspector should be tied to a lifecycle at the end of which we can flush the right classes.
> Here's an example to illustrate the problem.
> - Assume an app has JAXB databinding and that the default binding impl will require transformation from JAXB
> - Assume, on each invocation, the app client calls SCAClient.getServiceReference() to dynamically create a ref to a target component service
> - Assume the target component service, though part of the same Node, has a different app Classloader as the client
> - So the getServiceReference() will ultimately create a brand new JavaInterface, (the way ComponentContextImpl is coded today), 
> which will cause brand new wrapper classes to be generated
> - On data mediation, the JAXBWrapperHandler methods called by Input2Input/Output2OutputTransformer will result in an introspection of the wrapper classes
> - Since the introspection, leading to Class obj caching, happens on every invocation, the mem leak progresses quickly
> Now...this example lends itself to a different solution than what I suggested at the start, since you could look at caching the JavaInterface used to implement  SCAClient.getServiceReference().     
> Still, the issue appears even without dynamic refs.    There is no Introspector deregistration for a static ref either for a stopped client, or any deregistration for a stopped service.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.