yes in fact the MI is the only contextual environement besides the thread.
What I mean is that I was going to use it to collect information about what
is going on. It is almost a probe in the debug sense (send an MI and store
"came here" messages in it, that would be most helpful for deadlock studies,
I am a blind bat right now, no contextual information and the log is
useless).
So yes the idea of the MI and a repository of context information is an
excellent one,
would a simple map do? do you want it to be able to propagate?
I believe we should in fact move EVERYTHING to the map, the user the method
the tx everything
so that the MI is just a big
MI {
Map
}
and in the map we have pairs
user Object
method Object
params Object[]
myInformationThatIOnlyUseInMyOwnLittleApplication
Object[Maps[Array[OfMyStuff]]]]
etc etc etc...
would that cut it? yes we pay a price (map lookup) but it is on a small
map.
The only tricky part is that it needs to be serializable, (or not actually
but we would need to write the map item by item and catch the
non-serializability).
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of Jung
|, Dr. Christoph
|Sent: Thursday, June 28, 2001 4:05 AM
|To: '[EMAIL PROTECTED]'
|Subject: AW: [JBoss-dev] METHOD-INVOCATION (introducing profiling
|support)
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
