-----Urspr�ngliche Nachricht-----
>Von: David Jencks [mailto:[EMAIL PROTECTED]]
>Gesendet: Donnerstag, 18. Oktober 2001 17:36
>An: [EMAIL PROTECTED]
>Betreff: Re: [JBoss-dev] JMX detaching of invokers (RH/3.0)
>There is always a balance to be struck between on the one hand greater
>generality and flexibility with less compile-time type checking and less
>speed, and on the other hand a more specific solution that can be checked
>more by the compiler and includes scenario-specific optimizations. We have
>some hard decisions about where we want to end up on this continuum.
That is right. Especially when it comes to such a critical part as the
invocation engine.
>You are suggesting a map for invocation-specific properties of the method
>invocation (MI).
Yes, but if I think a while longer, we could do it like
class MethodInvocation {
String methodName;
String[] argumentClassNames;
byte[][] serializedArguments;
Object[] arguments;
byte[] serializedReturnValue;
Object returnValue;
Transaction tx;
...
Map additionalProperties;
}
where the most critical and core contexts are (de-)serialized with the
MethodInvocation in one shot
and are accessible in a type-safe manner and where, e.g., args and
returnValue have two representations
that are treated by a DeserializationInterceptor.
All other goodie-interceptors that you add may add additional context
in either serialized or deserialized form (entered as objects, vs. entered
as byte[], btw. how do you
wrap byte[] best?) to the additionalProperties map.
>We could do something similar with the
>interceptor-instance-specific state. A few days ago I discussed with Scott
>how to deal with interceptor-chain-instance specific interceptor state,
>such as the processed security proxy. He suggested keeping essentially the
>current system of individual interceptor instances for each chain, each
>with their chain specific state. I have started implementing the chain
>configuration based on this model. An alternate approach is to keep the
>interceptor state in a map attached to the chain head, and sent down the
>chain in the MI. Each interceptor can retrieve its state, if any, from the
>map in the MI. I find this model somewhat attractive, but would like some
>more opinions: right now I am following Scott's suggestion not to implement
>it.
I�m undecided whether the BIG flexibility of purely JMX-based invocation
routing
would be a performance-killer, or not.
Having the MI itself being the center of a strategy or command pattern
would be a very interesting
idea, though.
>If we pursue this model, with one interceptor of each type globally, shared
>by all chains, the question arises whether the "next" calls should be
>direct or through the mbean server via mbeanserver.invoke(...). On my
>machine, using jmxri, 100,000 direct calls take from 0 to 96 ms, whereas
>through the mbean server they take 10 sec. I'd like other opinions on
>whether this overhead is significant enough to dictate implementation, or
>whether an improved mbeanserver will make this negligible.
I simply don�t know. Especially since I did not have yet a
look into SUN�s JMXRI implementation.
CGJ
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
