Hi all,
let me generalize the argument of Anatoly a bit: It would be a tremendous
help, if MI would be
extendible, either by propragazing instances of MI-subclasses generated by
an appropriate factory,
and/or by an optional (initially empty) Map attribute that stores additional
ctx. Of course without
sacrificing performance, memory need, etc.
For example, for our ERP-logic, we are in need of propagating a Locale
(per user, even per incovation) which should influence the way certain
system services behave,
error messages are produced, lookups are made, etc but which should in no
way
be explicit in the business API.
I´m sure that there are and will be a lot more examples, where people would
like to extend the container
at particular "inner" places without having to cut&paste/subclasse the whole
invocation layer.
CGJ
-----Ursprüngliche Nachricht-----
Von: Anatoly Akkerman [mailto:[EMAIL PROTECTED]]
Gesendet: Mittwoch, 27. Juni 2001 23:23
An: [EMAIL PROTECTED]
Betreff: RE: [JBoss-dev] METHOD-INVOCATION (introducing profiling
support)
Hello, Marc and others.
This is a bit off-topic from the original thread but I've notices
something in Marc's answer that had strong resonance with my thoughts.
I am trying to come up with a comprehensive profiling support for J2EE
applications running on top of JBoss. This is necessary for a my research
project and I am pretty sure that if it is functional, it will be quite
useful for the overall JBoss userbase.
Here is a bag of ideas that has been collecting dust for a few days in my
head (after several discussions with my advisor).
A few words about my project. It has to do with adaptive distributed
applications. For those familiar with Akamai and what they do to static
content, start thinking how to achive the same with dynamic content. For
those who picture webservices, try to think how to distribute a webservice
to the edge servers (again ala Akamai). There is a whole slew of research
issues that is related to this but the main goal is to build first an
infrastructure to try out different ideas.
The short term goal is to take an arbitrary J2EE application and
dynamically deploy it on a bunch of nodes (this involves some smart
deployment tricks, like decomposing the original EAR, repackaging beans,
reconfiguring bean references, etc.) As a sample application we took
PetStore (so this explains my initial work on getting PetStore running on
JBoss and later on integration of Tyrex DTM into JBoss, to support
distributed transactions which is essential when deploying an app in a
distributed fashion).
Now, next step is to be able to collect meaningful profiling information
about a deployed application and develop an infrastructure to allow for
dynamic adaptation decisions for this applications (like deploying certain
beans on additional nodes to support additional clients, etc.) Think of it
as having the application shrink or spread between nodes to be able to
serve clients better.
The first step for this, is bringing in profiling support into JBoss. And
here profiling does not mean profiling in a sense of OptimizeIt and tools
like that, it is more of a tool to keep track of bean invocations as well
as some support to evaluate app server overheads.
Now getting back to the original topic METHOD INVOCATION. Here is how
it comes in. It seems to me that a method invocation carries
information which can be classified either as
- application invocation ctx (I tend to think it is just the method
params)
and
- container (really app server) invocation ctx (all the necessary
information to invoke the proper object with proper attributes, i.e. tx
context, security principal, object id)
It seems to me this is what Marc refered to when he said that we keep all
the necessary stuff in the MI.
Now, to introduce sophisticated profiling support (like being able to
detect hot paths in the application, etc.) There has to be another app
server managed invocation ctx object, namely, profiler ctx. Then,
a profiler can pass along with each call sufficient information (hopefully
minimal to minimize overhead, or null if profiling is disabled for an
app) to be able to construct meaningful profiling data.
Perhaps, my idea of where to introduce the profiler ctx support is flawed,
so please, tell me if you have better ideas. But the way I see it now, the
profiler ctx has to get passed along in the method invocation. (Both in
optimized local and in remote calls) Introducing this context will
necessarily involve changing all the inoke() calls that explicitly pass
along the tx, principal and credentials, so that now the call also
propagates profiler ctx. Wouldn't it be better if all the server-related
invocation contexts were wrapped together and passed along as one object,
so that changes like mine that introduce additional server-related
contexts would be easily handled by placing another field in the
ServerInvocationContext and not touching the Proxy and JRMP invoker and
other code.
If I am way too much off with my idea, please, tell me, I am open to
suggestions on what is a better way to introduce profiling support in
JBoss. Obviously, I would not submit any major changes to the invocation
layer prior to approval from the lead developers but I would hate to have
to maintain a forked CVS tree just to get me going with my project.
Yours truly,
-------------------------------------------------------------------------
Anatoly Akkerman
Computer Science Dept.
Courant Institute of Mathematical Sciences, NYU
719 Broadway, #715 Tel: 212 998-3525
New York, NY 10003 Fax: 212 995-4123
-------------------------------------------------------------------------
On Wed, 27 Jun 2001, marc fleury wrote:
> |When we get to support IIOP invocations, the CORBA
> |invocation transport layer automagically imports
> |incoming TPCs, and we never see a TPC that we can
> |import.
>
> Yes
>
> |That means that we cannot do the TPC import in the
> |transaction interceptors.
> |I guess the same argument goes for optimized local
> |calls.
>
> it is a question of context, who knows what the transport protocol is and
> who knows what the local transaction monitor is...
>
> |Always importing an incoming TPC in the invocation
> |transport layer (as CORBA does) is simple, as we
> |never have to consider TPCs, or how to import them.
>
> then the tl need to know about the tx that a given container uses... the
> simplest is to have an intermediary form in the MI
>
> transport specific TPC => MI.getTransaction (JBOSS ONLY) => TM specific TX
>
> |However the import may be costly in a distributed
> |system, and in some cases we do not need to import
> |the transaction because it will never be used in the
> |invocation (TX_REQUIRES_NEW for example). In case of
> |a distributed invocation of a TX_REQUIRES_NEW method
> |with a transaction context never used, we can save
> |at least two network round-trips per transaction, if
> |we can avoid importing the incoming TPC.
>
> sure, if we can save the last step it is good
>
> |The TPC import in the MI is simply a hack I did to
> |postpone the TPC import until we reach the TxInterceptor
> |where we know if we need to import the transaction, thus
> |enabling the above optimization.
>
> yes, I see that now, it is ok, it is called XP, put something we need in,
> then rework it :)
>
> |I am not religious about this, and if you think so,
> |I'll take it out again, and do the TPC import in the
> |invocation transport layer instead.
> |Going that route also has its advantages, as it will
> |simplify the code quite a bit: For example, it means
> |that the MI does not need to know *anything* about
> |transactions, as we always would have
> | MI.getTransaction() == TM.getTransaction()
> |and MI.setTransaction() would be superfluous.
>
> BUT WE WANT THE MI TO KNOW ***EVERYTHING*** ABOUT THE TRANSACTION IT
> PARTICIPATES IN.
>
> Ok I believe we should take the tpc out of there, but rely on the mi to
get
> the pointer to the tx
>
> That is a mistake a lot of the new readers of the code make. We want to
> keep the pointer to the tx INSIDE the MI. The reason is that it is much
> faster and the TM association is the only way ONLY when we are going
through
> interfaces that do not propagate that context (then we need to rely on the
> thread association). So.. leave it there, trust me, USE THE MI TO CARRY
> THAT TX.
>
> See the MI is a repository of information about the invocation going on.
>
> As we move to webservices (even if they don't propagate tx) we want the
> different MBeans in the JBOSS General Purpose Architecture to pass around
> message with all the information in it, including the tx they are
> participating in, I don't want to go to the tm every time and look up a
> thread map, so do not rely on anything implicit and the TM association is
an
> implicit one.
>
> |What do you think?
>
> good and bad, refactor the tpc out, the MI must remain clean, but don't
> factor the tx out, even if you can...
>
> :)
>
> marcf
>
> |
> |
> |Best Regards,
> |
> |Ole Husgaard.
> |
> |_______________________________________________
> |Jboss-development mailing list
> |[EMAIL PROTECTED]
> |http://lists.sourceforge.net/lists/listinfo/jboss-development
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
