I have got three questions. For the first two, I need just confirmation that
I have understood the matter correctly. For the last one, I do not have a
clue!
1. We are running two different windows-based applications at the same time
on one machine. How many CLR processes are we going to have? One or two? (I
reckon it must be two) Maybe process is a misnomer in this case (instance is
better) because CLR is loaded INTO the existing process.
2. In an ASP.NET application, if we do not change any settings (by default
applications will share the dllhost process), how many CLR process/instance
would we have? Probably one?? And what if applications do not share the
process? Does that mean we are going to have CLR overhead (and memory usage)
for each and every application?
1. In COM+, where the h... CLR is loaded?! Is it different for server or
library applications? Could you please elaborate on this?
Thanks in advance
Ali
Only One.
Shishir Kumar Mishra
Agni Software (P) Ltd.
www.agnisoft.com
> 1. We are running two different windows-based applications at the same
time
> on one machine. How many CLR processes are we going to have? One or two?
(I
> reckon it must be two) Maybe process is a misnomer in this case (instance
is
> better) because CLR is loaded INTO the existing process.--
The CLR is injected on a per process basis. If you run one OS process,
you'll get one instance of the garbage collector, one instance of the heap,
one of the stack, etc. That's how you can run two processes running under
two versions of the CLR.
> 2. In an ASP.NET application, if we do not change any settings (by default
> applications will share the dllhost process), how many CLR
process/instance
> would we have? Probably one?? And what if applications do not share the
> process? Does that mean we are going to have CLR overhead (and memory
usage)
> for each and every application?
Dllhost is used to limit the overhead of creating several processes for
windows services. The aspnet processor is a separate process that use the
CLR as well. Even if you don't share the process (isolation mode), there
will still be one CLR per version for the aspnet process I believe (could be
wrong though).
> 1. In COM+, where the h... CLR is loaded?! Is it different for server or
> library applications? Could you please elaborate on this?
If I'm not wrong (but a com+ guru could maybe clarify), in the case of in
process, first an SCP is created (Serviced Component Proxy), which activates
the COM+ context, and everything is done in process.
For server calls, there is a separate process, as the managed client
creating a server COM+ object creates the TransparentProxy, and then two
proxyies that are chained before crossing the process / computer boundary,
to find yet another proxy on the server side. The CLR as such is not shared,
which makes sense.
However, I believe in the case of a Server call to an EntrepriseServices
call, if the server component is on the same machine, I believe the thread
executing your code is hacked in a very interesting way. Instead of going
through any form of serialization / deserialization of the call, the thread
is put in kernel mode to cross the process boundary and gets out in the COM+
process. You pay for the context switch but this is far less than paying for
the remoting infrastructure for example.
Hope it helps.
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/
"Alireza Kheyrollahi" <alio...@aliostad.co.uk> a écrit dans le message de
news: %23bu6n08...@TK2MSFTNGP09.phx.gbl...
> Hi all,
>
> I have got three questions. For the first two, I need just confirmation
that
> I have understood the matter correctly. For the last one, I do not have a
> clue!
>
>
>
>
> Thanks in advance
> Ali
>
>
>
That is some real answer! I posted this on VB three times and did not
get any response. I congratulate you on your depth of knowledge.
I think that is nice to know how things work so that you can understand
pros and cons of an approach in a technology.
Do you mean that aspnet_wp.exe is responsible for loading CLR? So
ASP.NET ISAPI loads aspnet_wp.exe (where ISAPI is loaded? Probably IIS
itself)and uses talks to that.
I see now why basically you canot set it to "Low IIS Process" (you can
but it will ignore it and use Medium or Pooled) because you cannot host
ASP.NET on IIS simply because it came after that. But I still would like
to know what happens if you set it to "High (Isolated)".
I will have deeper look at the notions you mentioned about COM+ and will
come back to you but it just confirms that how cryptic is COM+ in .NET
world (or vice versa).
I wish other people would share their opinion too (possibly people from
Microsoft)
Many thanks
Ali
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/
"Ice" <i...@nospam.com> a écrit dans le message de news:
eH1mkEQr...@TK2MSFTNGP09.phx.gbl...
This information is really available on msdn, it is a shame this library is
nearly unusable if you don't have it locally on your computer! And also,
google is your friend. But it's always a pleasure to help. Take my words
with caution though, I didn't write the system and can only rely on what
I've seen and read on the subject.
> Do you mean that aspnet_wp.exe is responsible for loading CLR? So
> ASP.NET ISAPI loads aspnet_wp.exe (where ISAPI is loaded? Probably IIS
> itself)and uses talks to that.
The process is a bit complex, but still manageable.
For IIS5:
When an HTTP request comes in, it is processed by IIS (inetinfo.exe). As
.net is implemented as an ISAPI extension, it then goes through
ASPNET_ISAPI.dll, hosted directly in inetinfo.exe. It then try to see if
aspnet_wp.exe is loaded, if not it loads it, and then establish a named pipe
and sends all the data through it. ASPNET_WP.exe is the only one dealing
with managed code.
Isolation in .net code works through several AppDomains hosted in ASPNET_WP.
The isolation mode configured in IIS metabase is where an ISAPI dll is
loaded in dllHost as a separate process. As you see, if the isapi extension
is loaded externally, it will still forward to the aspnet worker process. If
you will, isolation mode is dead :)
As for IIS6, the kernel mode http extension (http.sys i believe) receives
the HTTP request directly, and have its own cache. In the case of graphics
and html files, it can very efficiently stream directly from the file system
to the network card without any overhead, as there's no context switch to
get back to user mode to go to either inetinfo.exe or aspnet_wp.exe. If it
does not have the cache, it will then forward to w3wp.exe directly,
circumventing inetinfo.exe. MSDN mentions that it is passed directly from
kernel mode, but in fact it does context switch in user mode to go to the
worker process.
IIS6 supports "application pools", where you can set high isolation. In this
case, instead of having one process with one AppDomain per application, and
AppDomains only being recycled, high isolation provides several instances of
w3wp.exe, each containing one AppDomain per application in the same
application pool. This gives you a very powerfull way to recycle your
processes and provide isolations on a "pool" basis, and is much more
granular than either the asp mode or IIS5 worker process mode.
Note that aspnet_wp.exe is replaced by w3wp.exe only if you don't use the
IIS5 compatible mode. If you do, you'll use the old aspnet_wp.exe and won't
be able to use application pools for .net.
> I will have deeper look at the notions you mentioned about COM+ and will
> come back to you but it just confirms that how cryptic is COM+ in .NET
> world (or vice versa).
It's not really cryptic. There is a big misunderstanding about the COM+
support in .net, and it's often mistaken for COM Interop support.
COM+ uses the remoting proxy feature to provide for several proxies, each
responsible for managing communication between different components. It's
all managed code that taps into the COM+ context model nearly natively (as
it's written in managed c++). The overhead is very very low. The only moment
where you do real interop is when you remote across computer boundaries, in
which case you go through DCOM. You do suffer some performance problems, but
once again, performance doesn't matter at all in a distributed architecture,
throughput does, so it's quite negligeable.
You are a real Guru! It is really nice to know that there are knowlegeable
and ALSO nice people
out there ready to help. God bless you.
Yours
Ali
"Sebastien Lambla" <sebastie...@6sens.com> wrote in message
news:OEkezmRr...@TK2MSFTNGP09.phx.gbl...
--
Sebastien Lambla
http://thetechnologist.is-a-geek.com/blog/
"Alireza Kheyrollahi" <alio...@aliostad.co.uk> a écrit dans le message de
news: Ob6NYOT...@TK2MSFTNGP10.phx.gbl...
I know it is a bit late to come back with more questions but we actually
reached the root high level question that made me investigate about "the
process thing":
How much of the .NET luxuries are safely but indirectly accessible in a COM+
environment and how does that work? What I mean is that I am inclined that
we should have a COM+ facade and behind that make the most of the luxuries
like static propeties (especially for caching) and polymorphism and ...
The problem is there are differences between "serviced component"
environment and fully managed code environment. If I do not know how my
appdomain is going to be created and destroyed, I cannot rely on shared
properties for caching. Also in COM+ environment "finalize" is called
immediately in case of SetAbort and SetComplete (well, if we do not use
object pooling and some other exceptions) which can be a bonus and help me
out.
I am afraid I have to dispute you on your opinion about simplicity of
enterprise services and stress again that it is cryptic! As you beautifully
explained, it involves a lot of behind the scene "safe" (oh yeah!)
"transparent" wrapping and hijacking of the poor object which isreminescent
of the bitter memories of VBCOM days (I still deal with DLL Hell). I believe
it is not a very good idea to fool people by doing transparent things that
you have no control on. I dislike ASP.NET because it fools you that web
programming is like windows programming, you simply code on events. This
might reduce amount of code but just makes it too easy to make silly
architectural mistakes.
You believe it is all in MSDN (and rightfully so) but I looked deep into it
and was not able to find it. And I carry title of MCAD.NET. If it is
difficult for me, how is it going to be for a junior programmer?
Alright nagging is enough!
Look forward to hearing about shared fields and ...
Yours
Ali
"Sebastien Lambla" <sebastie...@6sens.com> wrote in message
news:OTaAa1br...@TK2MSFTNGP09.phx.gbl...
> You believe it is all in MSDN (and rightfully so) but I looked deep into
it
> and was not able to find it. And I carry title of MCAD.NET. If it is
> difficult for me, how is it going to be for a junior programmer?
Agreed. MSDN is not easy to deal with unless you've read the whole thing,
has very good memory and can recall exactly the good keywords to get the
documents back :)
> How much of the .NET luxuries are safely but indirectly accessible in a
COM+
> environment and how does that work? What I mean is that I am inclined that
> we should have a COM+ facade and behind that make the most of the luxuries
> like static propeties (especially for caching) and polymorphism and ...
Well, exposing your objects as a COM+ object is yet another question, and
you do pay again in term of performance, and goes through a really different
interop call (through the use of yet another proxy, the RCW).
Frankly, I need to review a bit of the internals before digging too far into
it.
> The problem is there are differences between "serviced component"
> environment and fully managed code environment. If I do not know how my
> appdomain is going to be created and destroyed, I cannot rely on shared
> properties for caching. Also in COM+ environment "finalize" is called
> immediately in case of SetAbort and SetComplete (well, if we do not use
> object pooling and some other exceptions) which can be a bonus and help me
> out.
Well, you have no control over the AppDomain itself, that's absolutely true.
I don't know the details of EntrepriseServices AppDomain recycling, so I'll
have to dig into it and get back to you. However, I'm pretty sure the
AppDomain is not recycled when you just end up a transaction, and if you use
ObjectPooling, you should get the most throughput and just use your static
cache members for optimizing thigns. If you're only using transactions and
don't want to use object pooling or jit, then I would recomment strongly
against using an EntrepriseServices object in the first place :)
> of the bitter memories of VBCOM days (I still deal with DLL Hell). I
believe
> it is not a very good idea to fool people by doing transparent things that
> you have no control on. I dislike ASP.NET because it fools you that web
> programming is like windows programming, you simply code on events. This
> might reduce amount of code but just makes it too easy to make silly
> architectural mistakes.
can't really agree. EntrepriseServices has been under promoted and under
explained, but you do keep a lot of control. You can have access to the
context information, you can do the work you need on activation and
deactivation to retrieve/store state... I guess I don't see the very
difficult or wizzard like interface that happens. If you choose automatic
transaction support, the rule is quite simple, if something throws,
rollback, else commit. If you do it manually it's even more explicit. I
guess I don't really get your point?