Board index » delphi » Graceful death?

Graceful death?

I have an apartment threaded DCOM server, which will be serving 2-10 or so
clients at a time. Each client having it's own object and thread in the
server to manage it's connection. I check periodically for the existence of
the client, and if it has crashed I allow the thread to exit and free it's
resources.

Each object needs to hold a reference to the "master" object that defines
the lifetime of the thread, to ensure that the thread doesn't prematurly
terminate if the client releases the main object while still using details.

The problem that I'm having is that in an abnormal client termination
calling CoUninitialize does not guarantee any sort of order in releasing
objects. If the master object is released before the details, they will
crash when trying to release their reference to the master.

I attempted to solve this by having the master object keep track of it's own
reference counts, and having the details simply tell it when they are
created or destroyed. The master object keeps a list of current children.
When terminating I have the master CoDisconnect each child, CoDisconnect
itself, then clean out it's message queue to get resulting Releases. I then
force the unloading of each child object by Releasing until it returns 0.  I
then do the same on the master object. Only then do I call CoUninitialize.

As near as I can I'm being as careful as I can, but I'm still crashing in a
Release in CoUninitialize.

Any ideas?

--
Darren Clark
Product Architect
OpenTable.com
P 415.551.1510 x228
F 415.551.1441
Book your real-time restaurant reservations at http://www.opentable.com

 

Re:Graceful death?


Darren,

Why do you check for the existence of the client yourself?
As far as I know DCOM takes care of it using pingsets and
other complicated machinery. The only problem with that is
that the timeouts are not configurable and are quite large, some
10 minutes or so.

For your server, it will look like normal Release() on your object,
or, if you make outgoing call to the crashed client, E_DISCONNECTED.
In the latter case, call CoDisconnectObject on any interfaces you
may hold, and shut down the thread in the normal way.

It works, but while debugging, no one has enough patience :)

Good luck!
    Alex

Quote
Darren Clark wrote in message <7tbn8g$r...@forums.borland.com>...
>I have an apartment threaded DCOM server, which will be serving 2-10 or so
>clients at a time. Each client having it's own object and thread in the
>server to manage it's connection. I check periodically for the existence of
>the client, and if it has crashed I allow the thread to exit and free it's
>resources.

>Each object needs to hold a reference to the "master" object that defines
>the lifetime of the thread, to ensure that the thread doesn't prematurly
>terminate if the client releases the main object while still using details.

>The problem that I'm having is that in an abnormal client termination
>calling CoUninitialize does not guarantee any sort of order in releasing
>objects. If the master object is released before the details, they will
>crash when trying to release their reference to the master.

>I attempted to solve this by having the master object keep track of it's
own
>reference counts, and having the details simply tell it when they are
>created or destroyed. The master object keeps a list of current children.
>When terminating I have the master CoDisconnect each child, CoDisconnect
>itself, then clean out it's message queue to get resulting Releases. I then
>force the unloading of each child object by Releasing until it returns 0.
I
>then do the same on the master object. Only then do I call CoUninitialize.

>As near as I can I'm being as careful as I can, but I'm still crashing in a
>Release in CoUninitialize.

>Any ideas?

>--
>Darren Clark
>Product Architect
>OpenTable.com
>P 415.551.1510 x228
>F 415.551.1441
>Book your real-time restaurant reservations at http://www.opentable.com

Re:Graceful death?


What error are you getting when you crash at Couninit time?

--
Binh Ly
Visit my COM Notes at http://www.castle.net/~bly/com

Quote
Darren Clark <dcl...@opentable.com> wrote in message

news:7tbn8g$rrc9@forums.borland.com...
Quote
> I have an apartment threaded DCOM server, which will be serving 2-10 or so
> clients at a time. Each client having it's own object and thread in the
> server to manage it's connection. I check periodically for the existence
of
> the client, and if it has crashed I allow the thread to exit and free it's
> resources.

> Each object needs to hold a reference to the "master" object that defines
> the lifetime of the thread, to ensure that the thread doesn't prematurly
> terminate if the client releases the main object while still using
details.

> The problem that I'm having is that in an abnormal client termination
> calling CoUninitialize does not guarantee any sort of order in releasing
> objects. If the master object is released before the details, they will
> crash when trying to release their reference to the master.

> I attempted to solve this by having the master object keep track of it's
own
> reference counts, and having the details simply tell it when they are
> created or destroyed. The master object keeps a list of current children.
> When terminating I have the master CoDisconnect each child, CoDisconnect
> itself, then clean out it's message queue to get resulting Releases. I
then
> force the unloading of each child object by Releasing until it returns 0.
I
> then do the same on the master object. Only then do I call CoUninitialize.

> As near as I can I'm being as careful as I can, but I'm still crashing in
a
> Release in CoUninitialize.

> Any ideas?

> --
> Darren Clark
> Product Architect
> OpenTable.com
> P 415.551.1510 x228
> F 415.551.1441
> Book your real-time restaurant reservations at http://www.opentable.com

Other Threads