directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Many threads started by Ehcache when running core-integ
Date Wed, 24 Nov 2010 10:13:55 GMT
On Wed, Nov 24, 2010 at 10:10 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> On 11/24/10 8:58 AM, Stefan Seelmann wrote:
>>
>> Hi guys,
>>
>> I had (and still have) problems running the core-integ tests on a
>> Windows 7 VM. A first analysis using jvisualvm showed that for each
>> test two new threads were started from Ehcache and never stopped. The
>> cause is that for each new DirectoryService instance a new
>> CacheManager is created in CacheService.
>
> Don't we shutdown the CacheManager when the DS is stopped ?
>>
>> To solve that problem I tried to to call CacheManager.shutdown() in
>> CacheService.destroy(). However then the DNFactory didn't work any
>> more because it uses a static reference to the cache and that could be
>> a shutted down instance.
>
> I guess you answered my question :) And this is bad design if the DNFactory
> uses a static cache reference.
>>
yeap, indeed, I have blindly made this static to be able to set it
from other tests
(wrongly presuming that we don't initialize this way from any other place)
>> So the next step was to transform the static DNFactory. I renamed
>> DNFactory to DefaultDNFactory, extracted an DNFactory interface and
>> removed some unused methods. The DNFactory is now an instance of the
>> directory service and managed by the directory service. A consequence
>> is that some test classes can't use the DNFactory any more because it
>> needs to be initialized by the DirectoryService.
>
> That's a good move; And regarding the DNFactory, we just have to define a
> mock DS to create the needed cacheManager.
>>
>> In the end we still create a new CacheManager (which starts its two
>> threads) for each test but the threads are stopped after each test.
>
> Great ! Thanks for having dealt with this issue.
>
> Designing an efficient cache system is not easy... I don't blame anyone for
> he current design, it's just that it's hard.
>
it would have been better if I have had checked it again, this is a
mistake on my part
Thanks for the insight and for fixing it Seelmann

-- 
Kiran Ayyagari

Mime
View raw message