Bugzilla – Bug 2397
optimize rft request if running in same container
Last modified: 2006-04-06 09:55:09
You need to
before you can comment on or make changes to this bug.
If RFT and MEJS are running in the same container, then a local invocation
should be made instead of
going through the container's SOAP stack.
The call should still go through the SOAP stack, but it will just be via local
Java transport instead of http
See http://www-unix.mcs.anl.gov/~gawor/developer_notes.php under "Local
Adding missed email comment from Joe Link:
does going through the soap layers imply serialization? if so, i'd
think that's what you want to avoid at all costs.
From the URL in comment #1:
"Services in the container can be invoked locally. Local invocations work just like remote invocations (all
handlers are called, messages get serialized/deserialized) but messages do not travel over the network
- everything happens in memory."
I think the major problem is the contexts that are assumed by the services. Hacking around that to, for
example, establish an appropriate security context would be a royal pain. The performance gain from
doing so would probably not justify the effort.
The link to the documentation has changed. It's now a part of the main doc
instead of a personal page of Jarek's:
I guess local transport doesn't work without a pre-existing MessageContext.
Jarek said the core code could probably be altered to not require this, but the
priority for making the changes is pretty low right now. I'm going to mark this
as INCOMPLETE and save my changes to a branch. I'll also create an enhancement
request for this and set that as a dependency.
Local transport was implemented in globus_4_0_branch by caching the message
context. The trunk has the fix for 2926, so local transport just works in HEAD.