cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Antwort: RE: No memory leak because of Recyclable!
Date Tue, 13 Jan 2004 12:36:12 GMT

>Lars Rottmann wrote:
>> >>Lars Rottmann wrote:
>> >> Replacing the BucketMap with another Map implementation solves the
>> >> problem of Cocoon failing at high load (where the ECM fails to look
>> >> a Selector, not the Selector looking up a handler). It does not cure
>> >> the warning message above.
>> >Where do you replace the BucketMap with a Map? In the ECM?
>> >Did you try to do this replacement in the ExcaliburComponentSelector as
>> well?
>> I did replace every occurence of StaticBucketMap in the
>> Excalibur-Component
>> package with a Hashtable.
>Ah, ok - so, it seems that the BucketMap has threading problems. Replacing
>it with a HashMap solved the problem in the ECM.
>But replacing the BucketMap in the ECMSelector doesn't solve the other
>problem, as you still get the message. So, there must be another problem
>I know this is obvious, but I just wanted to restate it. I think we can
>assume that the HashMap has no threading problems.
>So, has anyone a clue? Can it be the toString() method on your operating
>system? Hmm, I don't know.

Hm we don't have this effect on our machine and we have a lot of traffic.
The only difference in our ECM Implementation is, that I have changed
ExcaliburComponentSelector to use the component as the key and not
component.toString(). I changed this to use the same implementation the
ExcaliburComponentManager use. Yes ECM uses the component as key and ECS
use component.toString(). I wanted in our Implememtation to make sure that
ECS work if somebody implements the toString method.
I don't believe that this can be the problem, because then it can be no
difference between HashTable and StaticBucketMap.

But may be, give it a try. I have no other idea.


View raw message