Sylvain Laurent (JIRA | 3 Oct 2008 10:16
Picon
Favicon

Created: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil

Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
-------------------------------------------------------------------------

                 Key: IBATIS-540
                 URL: https://issues.apache.org/jira/browse/IBATIS-540
             Project: iBatis for Java
          Issue Type: Bug
          Components: SQL Maps
    Affects Versions: 2.3.3, 2.3.4
            Reporter: Sylvain Laurent
         Attachments: ibatis patch for classloader memleak.txt

I'm using iBatis in a webapp with Spring and facing memory leaks upon redeployment oft he webapp.
I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a static ThreadLocal factorySettings

The problem is that the value bound to a Thread through this ThreadLocal is never nullified, and since the
"factorySettings" is a static variable, the ThreadLocal instance is reachable as long as the
ClassLoader of the webapp is reachable. But since the FactorySettings instance is bound to the Thread
through a strong reference (see the JDK implementation of ThreadLocal in ThreadLocalMap$Entry), the
classloader is finally never collected...

The solution is to always cleanup the ThreadLocal after usage (in SqlExecurtor)
I attach a patch for iBatis 2.3.4 to this issue

Sylvain Laurent (JIRA | 3 Oct 2008 10:22
Picon
Favicon

Commented: (IBATIS-376) Hot deploy issue


    [
https://issues.apache.org/jira/browse/IBATIS-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636570#action_12636570
] 

Sylvain Laurent commented on IBATIS-376:
----------------------------------------

I opened a new issue IBATIS-376 for a different leak.

The leak in this IBATIS-376 issue does not occur in my case because Spring's iBatis support does not make use
of getLocalSqlMapSession(), but rather use openSession().

> Hot deploy issue
> ----------------
>
>                 Key: IBATIS-376
>                 URL: https://issues.apache.org/jira/browse/IBATIS-376
>             Project: iBatis for Java
>          Issue Type: Improvement
>          Components: SQL Maps
>    Affects Versions: 2.2.0
>         Environment: ALL
>            Reporter: kevin chae
>         Attachments: SqlMapClientCleaner.zip
>
>
> Hi Clinton and team.
> I found an interesting issue.
> In case of hot deploy
(Continue reading)

Kai Grabfelder (JIRA | 3 Oct 2008 13:08
Picon
Favicon

Commented: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil


    [
https://issues.apache.org/jira/browse/IBATIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636605#action_12636605
] 

Kai Grabfelder commented on IBATIS-540:
---------------------------------------

doesn't this has a performance impact? What's the point of using the ThreadLocal if it is cleaned just right
after it has been set?

> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
> -------------------------------------------------------------------------
>
>                 Key: IBATIS-540
>                 URL: https://issues.apache.org/jira/browse/IBATIS-540
>             Project: iBatis for Java
>          Issue Type: Bug
>          Components: SQL Maps
>    Affects Versions: 2.3.3, 2.3.4
>            Reporter: Sylvain Laurent
>         Attachments: ibatis patch for classloader memleak.txt
>
>
> I'm using iBatis in a webapp with Spring and facing memory leaks upon redeployment oft he webapp.
> I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a static ThreadLocal factorySettings
> The problem is that the value bound to a Thread through this ThreadLocal is never nullified, and since the
"factorySettings" is a static variable, the ThreadLocal instance is reachable as long as the
ClassLoader of the webapp is reachable. But since the FactorySettings instance is bound to the Thread
through a strong reference (see the JDK implementation of ThreadLocal in ThreadLocalMap$Entry), the
(Continue reading)

Sylvain Laurent (JIRA | 3 Oct 2008 15:10
Picon
Favicon

Commented: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil


    [
https://issues.apache.org/jira/browse/IBATIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636625#action_12636625
] 

Sylvain Laurent commented on IBATIS-540:
----------------------------------------

According to the comments in the original class, it was a way of passing around some data without changing
the prototypes of many methods.
There's no performance impact, anyway the ThreadLocal is setup before each call. My patch just clean it up
after the call

> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
> -------------------------------------------------------------------------
>
>                 Key: IBATIS-540
>                 URL: https://issues.apache.org/jira/browse/IBATIS-540
>             Project: iBatis for Java
>          Issue Type: Bug
>          Components: SQL Maps
>    Affects Versions: 2.3.3, 2.3.4
>            Reporter: Sylvain Laurent
>         Attachments: ibatis patch for classloader memleak.txt
>
>
> I'm using iBatis in a webapp with Spring and facing memory leaks upon redeployment oft he webapp.
> I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a static ThreadLocal factorySettings
> The problem is that the value bound to a Thread through this ThreadLocal is never nullified, and since the
"factorySettings" is a static variable, the ThreadLocal instance is reachable as long as the
(Continue reading)

Kai Grabfelder (JIRA | 3 Oct 2008 15:52
Picon
Favicon

Commented: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil


    [
https://issues.apache.org/jira/browse/IBATIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636636#action_12636636
] 

Kai Grabfelder commented on IBATIS-540:
---------------------------------------

cool, then I guess it is save to apply it ;-).  <at> Devs? What do you think?

> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
> -------------------------------------------------------------------------
>
>                 Key: IBATIS-540
>                 URL: https://issues.apache.org/jira/browse/IBATIS-540
>             Project: iBatis for Java
>          Issue Type: Bug
>          Components: SQL Maps
>    Affects Versions: 2.3.3, 2.3.4
>            Reporter: Sylvain Laurent
>         Attachments: ibatis patch for classloader memleak.txt
>
>
> I'm using iBatis in a webapp with Spring and facing memory leaks upon redeployment oft he webapp.
> I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a static ThreadLocal factorySettings
> The problem is that the value bound to a Thread through this ThreadLocal is never nullified, and since the
"factorySettings" is a static variable, the ThreadLocal instance is reachable as long as the
ClassLoader of the webapp is reachable. But since the FactorySettings instance is bound to the Thread
through a strong reference (see the JDK implementation of ThreadLocal in ThreadLocalMap$Entry), the
classloader is finally never collected...
(Continue reading)

Jeff Butler | 3 Oct 2008 15:58
Picon

Re: Commented: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil

+1.  I'll do it.

Jeff Butler

On Fri, Oct 3, 2008 at 8:52 AM, Kai Grabfelder (JIRA)
<ibatis-dev <at> incubator.apache.org> wrote:
>
>    [
https://issues.apache.org/jira/browse/IBATIS-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636636#action_12636636 ]
>
> Kai Grabfelder commented on IBATIS-540:
> ---------------------------------------
>
> cool, then I guess it is save to apply it ;-).  <at> Devs? What do you think?
>
>> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
>> -------------------------------------------------------------------------
>>
>>                 Key: IBATIS-540
>>                 URL: https://issues.apache.org/jira/browse/IBATIS-540
>>             Project: iBatis for Java
>>          Issue Type: Bug
>>          Components: SQL Maps
>>    Affects Versions: 2.3.3, 2.3.4
>>            Reporter: Sylvain Laurent
>>         Attachments: ibatis patch for classloader memleak.txt
>>
>>
>> I'm using iBatis in a webapp with Spring and facing memory leaks upon redeployment oft he webapp.
>> I tracked the leaks to ibatis, where the class ResultObjectFactoryUtil has a static ThreadLocal factorySettings
(Continue reading)

nospam@kaigrabfelder.de | 3 Oct 2008 17:36
Picon
Favicon

ibator - current status

Hi Jeff,

whats the status of the ibator eclipse plugin? Can we help you in any way? Is the current trunk version
already stable enough to test it and file jira issues for it?

Regards

Kai

Jeff Butler | 3 Oct 2008 18:12
Picon

Re: ibator - current status

I'm working on a pretty significant refactoring of ibator.  The tests
are running successfully, but I still have some work to do related to
changes in the configuration DTD.

The goal of the refactoring was to get away from huge classes with
1000's of lines of code - it was too difficult to maintain and not
really OO.  It's better now.

This will also change (and simplify) supplying your own
implementations to ibator if you want to override any of the default
behaviors.

As for status and timing - I think I'll be able to check in the first
cut of the refactoring soon, maybe even this weekend.

If anyone wants to help, I think a good area to start on would be in
the Eclipse arena.  I'd like to do an Eclipse launch configuration for
ibator, rather than the simple menu option of Abator.  If you are
interested in working on that, then you could try to do a launch
configuration for Abator with the existing plugin - it would be easy
to convert it to ibator once the time comes.

If you have issues/enhancements for ibator than you can feel free to
file JIRA issues, but don't spend much time on working with ibator
internals until I check in the refactored code - the internals have
changed significantly. (In case anyone is worried, the code generated
by ibator is virtually identical to code generated by Abator - but
there is a new method "insertSelective").

Jeff Butler
(Continue reading)

Jeff Butler (JIRA | 3 Oct 2008 18:20
Picon
Favicon

Closed: (IBATIS-540) Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil


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

Jeff Butler closed IBATIS-540.
------------------------------

    Resolution: Fixed

Fixed in SVN.

It was a bit more difficult than the patch suggested - because SqlExecuter can be called recursively if
there are nested sub-selects in result maps.  So I changed ResultObjectFactoryUtil to implement a Stack
rather than a single instance of the configuration.  This will also make the calls to the
ResultObjectFactory more accurate - because the statement id's will be correct in all cases (even if the
call is a result of a nested sub select).

I believe the issue is fixed, but if you find more issues feel free to reopen.

> Classloader memory leak because of ThreadLocal in ResultObjectFactoryUtil
> -------------------------------------------------------------------------
>
>                 Key: IBATIS-540
>                 URL: https://issues.apache.org/jira/browse/IBATIS-540
>             Project: iBatis for Java
>          Issue Type: Bug
>          Components: SQL Maps
>    Affects Versions: 2.3.3, 2.3.4
>            Reporter: Sylvain Laurent
>            Assignee: Jeff Butler
(Continue reading)

Richard Banks (JIRA | 7 Oct 2008 09:57
Picon
Favicon

Created: (IBATISNET-283) Result mappings should work with interfaces when QueryForObject is passed an existing object

Result mappings should work with interfaces when QueryForObject is passed an existing object
--------------------------------------------------------------------------------------------

                 Key: IBATISNET-283
                 URL: https://issues.apache.org/jira/browse/IBATISNET-283
             Project: iBatis for .NET
          Issue Type: Bug
          Components: DataMapper
    Affects Versions: DataMapper 1.6.1
            Reporter: Richard Banks

In the IBatisNet.DataMapper.DataExchange.DotNetObjectDataExchange class the method public
override void SetData(ref object target, ResultProperty mapping, object dataBaseValue)
 does a check against types using this statement:

   if ((type != this._parameterClass) && !type.IsSubclassOf(this._parameterClass))

The problem here is that IsSubclassOf doesn't check for interface implementations.  When 
_parameterClass is an interface you also need to check using 

type.GetInterfaces().Contains(this._parameterClass)

This would then allow for result mappings to use interfaces, which is really useful when you are using an IoC
container to instantiate the class being populated, for example:

ISale sale = Container.Resolve<ISale>();
...
Mapper.Instance().QueryForObject<ISale>("uspSelectSale", saleNumber, sale);

Thanks
(Continue reading)


Gmane