Re: Run code part (like threadproc) in separate process

Ami wrote:

ok, thanks for the details. I design, develop and market mail servers
  so I can touch base with MUA (Mail User Access) client design needs
and issues. :-)


Generally, COM designs often require you to use catch and exception
traps to handle unexpected results. Are you doing any of this?

    try
    {
       pCom->SendCommand("AUTH")

    } catch(SomeComException &e) {
       // OOPS!!!
       // Initiate graceful client/server session cleanup/shutdow=

    }

Of course, some errors are critical and harder to trap.


Sure.... Reading more your description....

First, as you are aware COM is notorious for complex thread design
issues. No easy stuff. So the API must be stable and/or properly use
especially for threaded applications.

So the first quick question to first get out of the way is how are
initializing COM? For example:

      CoInitialize(NULL)
      CoInitializeEx(0, COINIT_MULTITHREADED);

This can play a role but it also depends on the COM object itself in
what it expects and allows. For example, you may have the call the
above at each THREAD entry.

Anyway, assuming you are using POP3 or maybe IMAP, these are
client/server designs so each session must be viewed as independent
transactions. i.e, a mail pickup thread does not conflict with another
session mail pickup, sound obvious. I know. :-)

But the key point is that this may also be a server limit or improper
state machine issue.

   1) Server has connection limits as part of its MAIL AVS, BULK
      SPAMMER prevention system. Since all your clients will
      expose the same IP address to the server, it would be very
      easy to impose limits that MOST mail servers offer to
      operators.

   2) The client is not properly handle server response codes.

       A) Can put the transaction state machine in instable
          state.

       B) Server is aggressive and forces a disconnect for
          misbehavior clients.

and so on.

So your COM client software and how your implement it, must be robust
enough to watch for server reply codes - all of them and act according
and not try to continue an errant state thus possibly causing an
faults in the COM object because it didn't know how to handle the
session request/response state machine.

Trust me on this. The #1 problem in these IETF based client/server
request/response protocols is someone not following the rules or best
practices and in the mail world, the specifications are just as
ambiguous as C/C++ standards. Which means that not all mail clients
are created equal.

So Ami, what I would do, as I always do in situations like this, is
put on hold on the idea that you have a bug somewhere, yours or the
COM and get a client/server conversation trace LOG of your sessions.

This will eliminate the idea if this is server limitation issue and
whether the client/server state machine request/response is being
properly handled or not by the client.

Analyze the conversation between the client and server will be the
first thing to get out of the way here. You might be surprise to see
that one of the clients failed because it did not know how to get out
of certain situation. You might even see that it ignored a server
negative response (negative means do not continue) and when the client
continue - PUFF - the server forces a drop, which triggers a socket
error for the COM object, and the COM object failed. Maybe it did its
job and caught the socket drop as most clients are expected to do, and
it throw an exception that wasn't captured in your implementation?

Anyway, I would start with this before going further. Get the trace
log of the session conversation. All good mail software worth its
salt offers a way to log the session. If you can't get it at the
client, try to get it from the server side.

They key point is the transaction MUST be correct and understood from
start to end. The log will tell you this.

--