From: Zhang Biyun <bring.zhang_at_gmail.com>
Date: Sun, 19 Jul 2009 19:14:24 +0800

Hi,

The ConfigInterceptor mentioned in title is the following Java Class.
appserv-core/src/java/com/sun/enterprise/admin/server/core/ConfigInterceptor.java

The following two methods in ConfigInterceptor is troublesome.
The parameter callstack of preInvoke/postInvoke is supposed to the same
object,
but, in fact, the callstack is changing in multithread, even if
preInvoke/postInvoke are executed in the same thread. It is not thread-safe.

public void preInvoke(CallStack callstack)
public void postInvoke(CallStack callStack)

If callstack's state is not correct, a call that change configcontext
probably does not
flush configcontext and does not send notification. I think this is a
big issue.

Also, the implemention of callstack in ProxyClass verified that
the callstack is a thread sharing object.

admin-core/util/src/java/com/sun/enterprise/admin/util/proxy/ProxyClass.java

private static InheritableThreadLocal
callStackHolder = new InheritableThreadLocal() {
protected synchronized Object initialValue() {
return new CallStack();
}
};

Is it the right design that parent thread and all child threads share
the same callstack
object? Or, every thread holds a single callstack object?

★Attach a situation that a flush needed call doesnot flush configcontext.

1, setAttribute starts RMI Connection Thread 1.
2, RMI Connection Thread 1 changes the callstack.
3, RMI Connection Thread 1 executes the preInvoke method.
4, getAttribute starts RMI Connection Thread 2.
5, RMI Connection Thread 2 changes the callstack, and, now, the active call
is getAttribute's call.
6. when RMI Connection Thread 1 executes the postInvoke method, it
doesnot flush configcontext. Because the current active is
getAttribute's call
and it is not flush needed.

Thanks,
Zhang Biyun