Changing DCOM timeout value
Steve Short
trying to get my server to go on to it's next client without waiting(30
seconds) if there is a disconnection at one of the clients. This is a
problem since the server contacts most clients every 500 to 1000 ms to
update the data and at each attempt to update it hangs for the timeout
period before moving on. Thanks.
Alexander Nickolov
You'll have to wait for COM+ and W2K.
--
===============================
Alexander Nickolov, MCP
Panasonic Technologies Inc.
Speech Technology Laboratory
email: agnic...@geocities.com
===============================
Steve Short wrote in message ...
Tim Chipman
is not a valid answer, or at least we can't yet convince our customer of
that :)
Here's the scenario - in a manufacturing plant, many clients are connected
to one or more realtime data acquisition servers. Let's say that when the
pressure in a tank gets to a certain level, we want to shut off a valve.
Client A has a UI and contains the intelligence to assist in these decisions
to control the plant. Client B shows another UI and is in the VP of
Marketing's office. One day, the marketing VP decides to move his computer
and unplugs his ethernet cable while a client program is running that is
attached to the same server as Client A. Now the connection from the server
to Client B is lost, there's a 30 second delay, Client A never gets the
status change information in time, the tank explodes, and there are lawsuits
everywhere. Call it an extreme situation, but that is exactly the scenario
where this application is in use. Update rates are typically 10
milliseconds.
So, if there isn't any mechanism built into DCOM for changing the timeout
interval, then we'll need to roll our own mechanism. The first thing that
comes to mind is to launch a separate thread for each client, though that
doesn't seem to scale very well (we're talking >100 clients), so that's not
an option.
Another mechanism is to somehow have a watchdog thread along with one or
more data update threads. If a data update thread stalls for a given
timeout period, then the watchdog thread spawns an additional thread to take
over where the stalled thread left off. Maybe there's a queue consisting of
a list clients that need to be updated, and one or more threads act on
processing the queue?
Though using this thread-switching logic would seem to work, all of the
necessary CoMarshallInterthreadInterfaceInStream calls would seem to kill
performance. It seems as though the OS should handle this. The DCOM
timeout interval should vary depending on the network configuration and the
type of application. I can't believe Microsoft would hardcode an interval
like this anywhere - there's got to be at least some sort of undocumented
registry setting somewhere; I don't know if it can be handled in DCOM, RPC,
TCP/IP, or somewhere along the pipeline.
Any suggestions?
Alexander Nickolov <agnic...@geocities.com> wrote in message
news:#TORGqQv#GA....@cppssbbsa02.microsoft.com...
Ming-Ching Tiew
for each client. For I think that even if you use socket or RPC,
each socket or RPC connection might also block, but perhaps for
a short period.
Tim Chipman <tchi...@leadingchange.nospam.com> wrote in message
ul$zeXRv#GA....@cppssbbsa02.microsoft.com...
Greg Montgomery
1. You watch the return value of each DCOM call. If you get a
RPC_S_SERVER_UNAVAILABLE, or whatever else you're getting, you remove
that interface pointer from your list of clients. I just did this for
a server that is a IConnectionPoint source. Invalid clients were
causing our server to stall, so we check each call's return value and
when we get a bad hresult, we remove it from the list.
2. As you mentioned you could have a thread that does the calling. I
wouldn't have a thread for each client however. A smaller thread pool
would be fine since you probably aren't calling all these clients
simulataneously..
Greg
---
Greg Montgomery - remove dont spam me from return address
email is: greg.montgomery at synchrologic.com
Alexander Nickolov
need to be made. In a time critical environment STAs aren't a viable
solution.
Second, look up the IDL definition for IAdviseSink. This is one of the few
asynchronous notification interfaces in OLE. I have no further information
since I haven't delved into RPC interfaces (which seems necessary in
this case). Somebody else may be able to shed some light on how to
build asynchronous interface. Else, this will be a standard feature with
W2K and COM+ (or at least it is promised)...
--
===============================
Alexander Nickolov, MCP
Panasonic Technologies Inc.
Speech Technology Laboratory
email: agnic...@geocities.com
===============================
Tim Chipman wrote in message ...
>As another developer working on the same project, unfortunately
"impossible"
>is not a valid answer, or at least we can't yet convince our customer of
>that :)
>
>Here's the scenario - in a manufacturing plant, many clients are connected
>to one or more realtime data acquisition servers. Let's say that when the
>pressure in a tank gets to a certain level, we want to shut off a valve.
>Client A has a UI and contains the intelligence to assist in these
decisions
>to control the plant. Client B shows another UI and is in the VP of
>Marketing's office. One day, the marketing VP decides to move his computer
>and unplugs his ethernet cable while a client program is running that is
>attached to the same server as Client A. Now the connection from the
server
>to Client B is lost, there's a 30 second delay, Client A never gets the
>status change information in time, the tank explodes, and there are
lawsuits
>everywhere. Call it an extreme situation, but that is exactly the scenario
>where this application is in use. Update rates are typically 10
>milliseconds.
>
>So, if there isn't any mechanism built into DCOM for changing the timeout
>interval, then we'll need to roll our own mechanism. The first thing that
>comes to mind is to launch a separate thread for each client, though that
>doesn't seem to scale very well (we're talking >100 clients), so that's not
>an option.
>
mambrose
A)
Before you make the DCOM call that could block on a dead client, why don't
you send a vanilla TCP/IP ping-packet to it first? If you don't get an echo
within 50ms, you could skip the DCOM information-update for that machine.
If a machine misses three echoes in a row, assume it's dead and remove it
from the list.
This does have two drawbacks: it slows you down and you still could be
trapped if a machine dies after the packet but before the DCOM call. The
best you can say about this is that it will catch 99% of the dead-client
situations.
B)
Perhaps you could implement IMessageFilter::MessagePending() in your COM
server and then frequently (once per ms.?) post messages to yourself so that
it's invoked often. Then, if you detect a call that's gone on for too long,
you could return PENDINGMSG_CANCELCALL from MessagePending(). I've never
returned this value, so I'm not sure if it will work. Also, the MSDN help
seems to worry about returning this value. Nonetheless, it's worth a
look-see.
Please tell me if you find either of these ideas to be of value.
Michael Ambrose
mambrose@mail.<no-spam>.intracorp.com
mambrose
Ming-Ching Tiew
address this issue. However (not that I have proven this
approach not feasible) I didn't get to implement it.
Other factors need considerations could be :-
1. This approach is then putting a constraint to DCOM
to run over TCP/IP. Nothing so bad about this, but
the client has to register its IP with the server.
2. A small timeout value ( 50ms ? ) will also inherently limiting
implementation to a local area network. Nothing so bad
about this if this is the intended use. If a bigger timeout
value is allowed, then the same problem of one stale
connection holding up the update needed for other clients
will still exist.
mambrose <mamb...@intracorp.com> wrote in message
#wwe7Nlv#GA.318@cppssbbsa04...