multithreaded DCOM server

[Felix Kasza [MVP]]

Illia,

> What is the simplest way to create a worker thread pool in my server ?

Huh? RPC (and DCOM, by virtue of being based on RPC) servers do that
for you, if you allow it (MaxCalls arg in RpcServerRegister*(),
RpcServerListen() calls).

Cheers,
Felix.

----------
If you post a reply, kindly refrain from emailing it, too.

[Valery Pryamikov]

Ilia,
I think that MTS is what you are looking for.
check:
<http://www.microsoft.com/transaction/default.asp>

Valery.

Ilia A. Baymetov <i...@crec.mipt.ru> wrote in article
<01bc0933$978e03a0$a98e7dc1@dragon>...
> Hello.
> I have some questions relared to pooled threads.
>
> I have server apps, accessed by clients via RPC and DCOM.
> I mean that I don't use hand-crafted protocols thru manually open pipes
or
> sockets.

> What is the simplest way to create a worker thread pool in my server ?

> Could completion ports still be used and how ?
> Could it be done in more or less simple fashion ?
> Thanks in advance. Bye.
> --
> Regards, IL
>
>

[Felix Kasza [MVP]]

Mats,

> Is this in some way handled automatically by DCOM or is it something I
> have to do to get this functionality. If it is handled automatically,
> is there any docs available somewhere on that subject?

Ever since I posted my original reply, I have been digging for
information -- without success so far. Let me dig some more.

[Mats Ljungqvist]

fel...@dms.shd.de (Felix Kasza [MVP]) wrote:
>Huh? RPC (and DCOM, by virtue of being based on RPC) servers do that
>for you, if you allow it (MaxCalls arg in RpcServerRegister*(),
>RpcServerListen() calls).

I had a similar question, but I only plan on using DCOM.

If I set up an EXE server to act as a middle tier in a three-tier
architecture and communicate with it using DCOM how do I get it to
create multiple threads for multiple incoming client connections?

Is this in some way handled automatically by DCOM or is it something I
have to do to get this functionality. If it is handled automatically,
is there any docs available somewhere on that subject?

What I would like is a thread per executing object, perhaps not
necessary one thread per client, but a pool of threads serving a
couple of clients at a time, while the others wait for an available
thread.

I'm looking at Microsoft Transaction Server, but I haven't decided if
it will suite our needs yet. It's DB connectivity seems to lack some
of the stuff we need, so far, although it indeed have a lot of other
neat fetures I would love.

// Mats

---
Mats Ljungqvist E-mail: mats.lj...@enator.se
Enator IT System AB Phone : +46 8 749 81 28
Stockholm Fax: +46 8 99 80 29
SWEDEN Disclaimer: Standard!

Author of Notify CD Player for Windows 95 / NT 4.0
available at http://www.artech.se/~mlt/software/index.html

[Mats Ljungqvist]

Felix,

> > Is this in some way handled automatically by DCOM or is it something I
> > have to do to get this functionality. If it is handled automatically,
> > is there any docs available somewhere on that subject?

>Ever since I posted my original reply, I have been digging for
>information -- without success so far. Let me dig some more.

Sure! I'm digging myself!

I've been searching the latest MSDN Library and the KB on
www.microsoft.com/kb as well as www.microsoft.com/oledev which mostly
seems to talk about VB and automation which is not what I want.

Perhaps I've missed something, but it sure would be nice to know how
MTS can redirect incoming interface method calls to a free thread in
the thread pool or even redirect an entire object instance to a
specific thread so that all calls to that instance runs on the same
thread all the time.

The only place I can imagine this taking place in is in the RPC proxy
(or some RPC helper code) on the server side where my call arrives
before going into my actual DCOM interface method.

The COM objects supported by MTS doesn't need to do anything special
to be apartment threaded (except for setting the Apartmend flag in the
Registry and being aware of it) from what I've seen, so there must be
something magic going on somewhere.

Well, I guess I'm just lost... :)

[Felix Kasza [MVP]]

Mats,

> Perhaps I've missed something, but it sure would be nice to know how
> MTS can redirect incoming interface method calls to a free thread in
> the thread pool or even redirect an entire object instance to a
> specific thread so that all calls to that instance runs on the same
> thread all the time.

The _theory_ is simple enough. What I am currently stuck with is
finding something that gives fine-grained control over the run-time
behaviour of DCOM.

Anyway, thread pooling is automagically done by RPC -- it's built-in,
and is in fact the default behaviour for an RPC server. I would assume
that, for single-threaded thingummies, the DCOM runtime explicitly
serializes calls by wrapping them with a mutex or critsec before
actually calling the interface method.

[Mats Ljungqvist]

fel...@dms.shd.de (Felix Kasza [MVP]) wrote:

> > Perhaps I've missed something, but it sure would be nice to know how
> > MTS can redirect incoming interface method calls to a free thread in
> > the thread pool or even redirect an entire object instance to a
> > specific thread so that all calls to that instance runs on the same
> > thread all the time.
>The _theory_ is simple enough. What I am currently stuck with is
>finding something that gives fine-grained control over the run-time
>behaviour of DCOM.
>Anyway, thread pooling is automagically done by RPC -- it's built-in,
>and is in fact the default behaviour for an RPC server.

Yes. I've found that RPC seems to handle threading by default, but as
You say, it would be nice to know if I can in some way change the
settings for it. RpcServerListen has a *MINIMUM THREAD* parameter! It
also have an MaxCalls parameter. The docs says that RPC treats the
MaxCalls parameter as a "suggested limit"... Huh? So, how on earth
will I know if it will create threads for all incoming calls or just a
couple of them?

The architecture I'm talking about ranges from 10 to 12,000 (!)
clients! In the latter case it will of course utilize multiple servers
for the business objects, but it sure would be nice to know if there's
a limit somewhere.

BTW: One can wonder why the MTS docs wows the thread pool so much if
it in fact is built into RPC or do they do something additionally
magical?

>I would assume that, for single-threaded thingummies, the DCOM runtime explicitly
>serializes calls by wrapping them with a mutex or critsec before
>actually calling the interface method.

Yes, the latest MSJ has an article of such things, and it does indeed
serialize calls to objects that doesn't say otherwise.

Hey! I just checked my little DCOM test I did. I marked the server
object to handle "Both" threading models and then started creating
lots of client processes on my other machine. The server process
suddenly had 4 threads (of which I'm responsible for one, the main
thread). I then called a method in each client process that shows a
MessageBox on the server, and thereby locking that thread until I
click ok on the other machine. Suddenly the server process had 17
threads! So it appears like RPC is creating threads when it's needed,
i.e. when all available threads are busy. After clicking ok in all
message boxes on the remote machine it removed all threads except
four.

Hm... if there only is a way to control this too!

[Felix Kasza [MVP]]

Mats,

> So it appears like RPC is creating threads when it's needed,
> i.e. when all available threads are busy. After clicking ok in all
> message boxes on the remote machine it removed all threads except
> four.

Your observations are correct. RPC will always try to assign a thread
to a request; if no thread is available, a new one will get created
after a short delay; if MaxCalls has been hit, the request stays in
the queue.

As for the rest of it, I am beginning to believe that there's no way
to adjust MaxCalls for DCOM.

[Mats Ljungqvist]

fel...@dms.shd.de (Felix Kasza [MVP]) wrote:

>Your observations are correct. RPC will always try to assign a thread
>to a request; if no thread is available, a new one will get created
>after a short delay; if MaxCalls has been hit, the request stays in
>the queue.

Ok.

>As for the rest of it, I am beginning to believe that there's no way
>to adjust MaxCalls for DCOM.

Ouch! Any clue on what MaxCalls is set to by DCOM? Perhaps this is
somehow dynamic depending on the performance of the machine, since the
docs state that RPC treats this value as a suggested max value...