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