Re: Session ending shutdown problem
- From: r norman <r_s_norman@xxxxxxxxxxxx>
- Date: Thu, 19 Feb 2009 19:24:59 -0700
Thank you for your response which is, as always, very enlightening and
informative. As you have already seen, the problem is my overall
system design, one which I already admitted has been cobbled together
over many years and decades and which is now too large to revise
readily or, more to the point, for free. And there is so far no great
call to switch to a completely new system design even with a
significant number of improvements. That reluctance is probably
because the existing system was paid for gradually over the years and
decades whereas the new one will cost a similar large bundle up front.
The main thing that waits for closing during my derived CWinApp is my
event log which is created very early and shut down at the very end
specifically to allow me to capture problems during startup and
shutdown, something that was enormously useful during program
development. I agree it is no longer useful design, but it was handy
at the time and very easy. Having a final statement inserted into my
private event log (not the system one) right at the end assures me
that everything really did shut down properly. However that benefit
alone is now revealed to cause other problems, problems that you point
out.
The database update is not so much of an issue. My main worry is
about data transmitted from external devices and informing them to
stop sending, often done only by breaking the TCP/IP socket. However,
most of this data is trivial. The chance that an important piece of
data would happen between QueryEnd Session (which is when Tom Serface
properly told me to do my save) and the actual shutdown of
communications is very small, small enough so I think I can risk it.
I am also providing the IT people with a separate program they can use
to cleanly shut down my applications. The problem is that I have
little confidence that all of them will actually bother to use it so
my system save on shutdown is really a second tier effort just for
this situation. That is why I feel that a high probability of saving
all the data is sufficient. If the client complains that it
eventually fails, I can simply point out that their staff is the one
who failed to follow the proper procedures. That doesn't win many
brownie points, but is something they can understand and accept.
Actually, another problem is that I really don't deal with the final
client. There is a main contractor that I subcontract for who
installs and has to maintain the twenty or so application instances
and who also has to maintain good relations with the final client
because my software is only a very small part of that relationship.
Also, there is not too great a relationship between the division the
final client is in, the actual software user, and the IT department.
All this is, no doubt, part of normal business dealings. It makes me
very happy that I don't deal in sales or client relations -- all I
have to do is deliver software that actually works pretty much all the
time and that gets quickly fixed if it doesn't. That keeps my
contractor happy.
On Thu, 19 Feb 2009 13:18:54 -0500, Joseph M. Newcomer
<newcomer@xxxxxxxxxxxx> wrote:
I think the timeout is 20 seconds..
THere is a fairly complex solution, which involves using WMI as a communication mechanism.
But it imposes a significant burden on you to figure out how to use it, and it means your
IT people would have to know how to use an app that shut down your apps, so it may not be
viable as a solution.
One problem is the fundamental architectural decisions you have made. If you have a
massively long shutdown time, you will have to rethink what it means to "shut down". For
example, if it is taking too long to communicate with the databases, one simplistic
approach is to instantly create a "transaction" file that captures all pending requests,
and start routing everything to it instead of the databases. You would immediately shut
down the databases (preferrably out of a separate thread) and any data that arrived after
this process starts gets appended to the transaction file instead. This would typically
be a faster operation. The way you append is Open/Append/Close each time, so that you
have minimum exposure to an abrupt shutdown.n When the program restarts, you then "spool
out" any pending transactions and send them to the databases as appropriate. So the idea
is to immediately upon shutdown notification replace the heavyweight database transactions
with lightweight file transactions that are intended to be robust-under-shutdown. When
you complete the transactions you have saved, you can delete the transaction file (and you
end up having to deal with what happens if another shutdown comes in during the
transaction despooling). I would remove ANYTHING that was in the destructor of the
CWinApp class; that is far, far too late to be doing anything important. Destructors
should be used for local cleanup only; anything dealing with databases needs to be handled
long before that (it also suggests that you have a lot of "global" variables in your
CWinApp class, which is really not a good decision)
joe
On Wed, 18 Feb 2009 17:52:50 -0700, r norman <r_s_norman@xxxxxxxxxxxx> wrote:
I have a number of MFC MDI applications that run constantly andJoseph M. Newcomer [MVP]
unattended, essentially as embedded systems, to monitor and control a
variety of system hardware. They do have a user interface to help
manage the system but every user action requires a password-controlled
logon. A password is also needed to exit the program by whatever
normal means.
The problem is that IT personnel do remote maintenance on all the
systems including these and they can't shut down the program easily --
a password entry box pops up on the remote system but nobody is there
to enter one! So they just shut down Windows and my application loses
data.
Of course I can detect the QueryEndSession and EndSession messages.
The problem (I think) is that my shutdown takes too long -- there are
perhaps a dozen socket connections and several database tables that
have to be closed cleanly and many score data structures with
internal states that all need serialization so the system can be
restored properly at startup.
Here are some details: If I initiate a program close at
QueryEndSession and return FALSE to halt further system shutdown,
everything works fine. If I initiate a program close at either
QueryEndSession or EndSession but allow the system to actually
shutdown, then my program is aborted before all the data can be saved.
Most of my system saving is done during ExitInstance but some is also
done at the d'tor of my CWinApp derived class.
My current workaround is to shut down on QueryEndSession, returning
FALSE and force the IT people to perform a second shutdown.
Alternatively I can provide them with a separate program that tells my
application to close cleanly, but there is no promise that I can get
all the IT staff to actually do that. I would like behave nicely,
though and shut down cleanly on a single EndSession.
Is this a known issue? Am I simply doing something wrong? I confess
(if it is not already obvious) that I really don't understand how
EndSession works. Actually, I don't understand how MFC shutdown
works, for example why posting WM_QUIT does not properly close the
program whereas posting WM_CLOSE does. It is exactly OnClose where I
require the password. Is there some way I can force EndSession
processing to wait until my program is completely done?
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Follow-Ups:
- Re: Session ending shutdown problem
- From: Joseph M . Newcomer
- Re: Session ending shutdown problem
- References:
- Session ending shutdown problem
- From: r norman
- Re: Session ending shutdown problem
- From: Joseph M . Newcomer
- Session ending shutdown problem
- Prev by Date: Re: MFC/VC Goldmine major update: http://mfcgoldmine.site90.net/
- Next by Date: How to draw a line ??
- Previous by thread: Re: Session ending shutdown problem
- Next by thread: Re: Session ending shutdown problem
- Index(es):
Relevant Pages
|
