Bug 2397 - optimize rft request if running in same container
: optimize rft request if running in same container
Status: RESOLVED
: GRAM
wsrf managed execution job service
: development
: Macintosh All
: P3 normal
: 4.0.2
Assigned To:
:
:
: 2926
: 2905 4197
  Show dependency treegraph
 
Reported: 2004-12-03 15:56 by
Modified: 2006-04-06 09:55 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-12-03 15:56:40
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.
------- Comment #1 From 2004-12-03 16:49:50 -------
The call should still go through the SOAP stack, but it will just be via local
Java transport instead of http 
or https.

See http://www-unix.mcs.anl.gov/~gawor/developer_notes.php under "Local
Invocations".
------- Comment #2 From 2005-01-14 15:51:45 -------
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.
------- Comment #3 From 2005-01-14 17:20:31 -------
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.
------- Comment #4 From 2005-03-10 15:03:28 -------
The link to the documentation has changed.  It's now a part of the main doc
instead of a personal page of Jarek's:

http://www-unix.globus.org/toolkit/docs/development/3.9.5/common/javawscore/developer/#LocalInvocations
------- Comment #5 From 2005-03-10 17:20:34 -------
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.
------- Comment #6 From 2006-04-06 09:43:53 -------
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.