Pid,Chris
Thanks for your reponses. Meanwhile, I have come up with the following
code in the app to clear threadlocals for a thread. I have a
ReflectionUtil class that actually sets the accessible to true on the
Field after obtaining it via reflection.
----------------------------------------------------------------------
Method getMc = ReflectionUtil.getDeclaredMethod(MethodCache.class,
"getMethodCache");
Object theObject = MethodCache.getInstance();
Map mcMap = (Map) getMc.invoke(theObject, null);
mcMap.clear();
Field dbfield =
ReflectionUtil.getDeclaredField(XMLUtils.class,
"documentBuilder");
ThreadLocal db = (ThreadLocal) dbfield.get(null);
if (db != null) {
db.remove();
}
ThreadLocal cache = (ThreadLocal) _cacheField.get(null);
if (cache != null) {
cache.remove();
}
-----------------------------------------------------------------------
Initial test suggests that this helps clear the threadlocals.
Srikanth
On 12/14/10 5:33 AM, Pid wrote:
> On 13/12/2010 20:56, Ebert, Chris wrote:
>> I haven't solved this specific issue but (when the object isn't directly
>> accessible, which I assume is the case) you could:
>>
>> 1) find the nearest accessible object to the field you want.
>> 2) get the field value using reflection, setting accessibility if need be.
>> 3) Do what you need to: clear the thread local, or store it in something
>> that will clear it, or at least expose the number of entries to your
>> monitoring system. Or replace it with a class that will cache things
>> properly (bounded, with well defined rules).
>> 3a) At the very least, once I have the thread local I can wrap some logging
>> around it and see where objects are coming in and going out. Often, it's a
>> fault in the application (a missed 'close' or other operation because
>> something wasn't wrapped in a try/finally.) No substitute for figuring out
>> what the problem really is.
>>
>> Sometimes I find out things about how stuff is initialized that I didn't
>> want to know, but there it is.
>>
>> Oh, and add a unit test to see that your fix actually works and keeps
>> working. You never know when someone will update the library, actually. It
>> might be you, a few months later...
>>
>> You might be able to solve the problem by clever swapping of some class in
>> the wsdd file (client or server, as appropriate) but figuring it out might
>> take a while, and unit testing the WSDD config often is harder than a bit of
>> reflection. Replacing a few implementations in the WSDD just so you can get
>> a particular bit of the Axis library to log the info you want is a little
>> convoluted, but I do it a lot 'cause Axis doesn't do lots of things the way
>> I want it to.
>
> I think the fix for:
>
> https://issues.apache.org/jira/browse/AXIS-1701
>
>
> http://svn.apache.org/viewvc/axis/axis1/java/trunk/src/org/apache/axis/utils/XMLUtils.java?view=markup
>
> introduced a leak, because it's not possible to clear the ThreadLocal
> value created. But I could be wrong...
>
>
> p
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
