Zhang,
This is in V2 I presume, given the pathname.
I had long suspected a serious problem in that area due to flaky
behavior. Perhaps that is the cause.
At one point I had gone in and made all the involved objects immutable
('final' fields), but that code was never approved for committal (came
to late in a release cycle).
Lloyd
On Jul 19, 2009, at 4:14 AM, Zhang Biyun wrote:
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team