[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Pnet-developers] Re: [Bug #2948] Loading assemblies from memory
From: |
Chris Smith |
Subject: |
Re: [Pnet-developers] Re: [Bug #2948] Loading assemblies from memory |
Date: |
Fri, 28 Mar 2003 18:43:22 +0000 |
User-agent: |
KMail/1.4.3 |
On Friday 28 Mar 2003 14:00, Gopal V wrote:
> Memory load will be really useful only if you're loading the class from
> the network or similar source. Java allowed that with custom class loaders.
Exactly. The DGEE operates on the assumption that the just class loads from
*somewhrere*, it just makes an internal Goldwater call to the 'Resource
Manager' to fetch the class bytecode. The Resource manager sources it from
*somewhere* - this makes the SEE/VRS and distributed (for resilience) DGEE
possible from the word go.
> If you had to load stuff off a network source or other remote repository
> memload would be very useful.
Which is why I'm trying to do this ! - The webservice/class thingy may indeed
come from across the network or some other slow repository, and because of
this the DGEE will want to cache it if it can. The minimum is that we'll end
up with the wservice in a memory buffer at the VM, and DGEEInvoke will want
to load it from there and not from disk.
Currently the pnetVM ignores the fact that it has it in memory and just loads
it off disc anyway - that's enough at the moment, but a fundamental design
feature of the DGEE is that webservice 'classes' are served by the Resource
Manager and not just grabbed of disk by any VM that wants one. At the moment
the DGEE is effectively loading each webservice _twice_ (once by the RM, and
once by the VM).
> But as of now , I think caching ILImage * makes more sense.
Ah, I see what you may be thinking!
We're not trying to load from memory to allow us to Cache the webservice,
we're loading from memory because that's the only place the webservice will
be available from!
Of course having it in memory means that we can cache it if we want -
something that is an absolute must if there is a chance that the webservice
may come from a slow resource.
So Gopal I'm not sure I understand exactly what you're driving at with the
caching of ILImage stuff because I still have the problem of executing
DGEEInvoke and from there trying to load the webservice class from memory.
(in simple terms:) Can I load DGEEInvoke into an ILImage, _and then_ also load
the 'webservice' from memory into the _same_ ILImage, so that when I invoke
the DGEEInvoke.DGEE_run() method of the ILImage it is able to reflect over
itself and the 'webservice' and call the required ws method?
[ Note on caching: Caching the constructed ILImage will be much better
performance wise, but I need to get an ILImage of DGEEInvoke AND the chosen
webservice together as a single entity ].
Lots to ponder on ! :o)
See yah tomorrow IRC 1000UTC
Chris
--
Chris Smith
Technical Architect - netFluid Technology Ltd.
"Internet Technologies, Distributed Systems and Tuxedo Consultancy"
E: address@hidden W: http://www.nfluid.co.uk