httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject A solution to the Win32 console problem
Date Sat, 17 Jun 2000 15:48:43 GMT

In a message dated 00-06-16 15:50:10 EDT, William Rowe writes...

> > From: Rodent of Unusual Size [mailto:Ken.Coar@Golux.Com]
>  > Sent: Wednesday, June 14, 2000 10:45 PM
>  > 
>  > RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL 
>  > NICE TO WRAP THESE UP:
>  > 
>  >     * Add a simple Win32 hold console open patch (wait for close or
>  >         the ESC key, with a nice message) if the server died a 
>  >         bad death (non-zero exit code) in console mode.
>  >       OtherBill is working on this, but is open to any hints for
>  >         forcing the unchecked 'Close Window on Exit' opt's behavior.
>  
>  Ok... I have a -really friggin simple- solution to the above problem.
>  
>  Change the invocation shortcut to
>  
>  %comspec% /k ApacheIcon.bat [whatever args here]
>  
>  Rem ApacheIcon.bat is provided for shortcut users to see the results of
>  Rem their commands without closing the console afterwards.
>  Rem Setting a shortcut to execute the Apache.exe command directly is
>  Rem acceptable, but you will not see any errors once Apache closes.
>  Rem You will need to review your error.log file to find the problem.
> 
>  @@serverrootdrive@@:
>  cd @@serverroot@@
>  Apache %*
>  Rem The Apache.exe program has terminated.  Type the exit command or
>  Rem click the window's close button to close this console window.
>  
>  Opinions?
>  William Rowe

* KEEPING THE WIN32 CONSOLE ON EXIT...

The /K option might cause some problems with watchdog style scripts
or batch files that are designed to re-start the server. If people
don't add specific 'exit' commands to their scripts to close the
console then you could end up with a box in the closet that
re-generates so many 'kept' console windows that the available memory
goes away and it will reach a point where the Server won't re-start
anymore and will probably have to be re-booted to get rid of all
the consoles.

Whenever I have seen the 'runaway open consoles' problem on
Win32 kick in it always hoses the box so bad that even
CTRL-ALT-DEL won't work when all the memory is finally
eaten away. Shutdown won't work either at that point.

It's usually power-off/on time which irks Web Admins
to no end and can't even be done from remote without the
good 'ol dial-up UPS option.

In fear and trepidation I offer the following alternative...

( NOTE: This does NOT provide a solution for GP Faults but
then neither does /K. Even a Win32 console that was started
with the /K 'keep' option will usually disappear in a puff
of smoke if the problem is a GP fault. The suggestion is
only for for tracking unexpected calls to 'exit()' ).

Whenever I unpack a new copy of Apache source I simply add
some macros to it that will 'catch' any calls to 'exit()'
and let me read any console messages and/or choose to let
the console go away. It does it on a TIMER if I am not there
so that it still functions 'normally' and the console will
be destroyed so watchdog scripts can get the right error
code and safely 're-start' without resources disappearing.

As an example... the macro below is about as simple as it
gets... but still retains the problem of 'holding up' the show
and scripts or batch files designed to handle error recovery won't
ever be able to kick in until someone presses a key...

#undef exit
#define exit(code) \
  printf("Press any key to perform exit(%d)...\n", code ); \
  while(!kbhit()); \
  exit(code);

The next macro is 'the real deal'...

It accounts for multi-threading and uses a timer so that
there is plenty of time to read the error message(s) but will
still 'continue normally' if no one is around and the console
still 'goes away'.

The best part about it is that it tells you EXACTLY where
the 'exit()' is happening includng source file name and
exact line number.

#ifdef WIN32

// EXIT CAPTURE MACRO

// Redefine the 'exit()' function so we can intercept all calls
// and have the chance to read the error message(s) before the
// console closes since it might not have been launched with
// the /K 'keep' flag...

CRITICAL_SECTION g_exit_interceptor_critical_section1;
long g_exit_interceptor_startup_time;
long g_exit_interceptor_current_time;
long g_exit_interceptor_elapsed_time;

// GetCurrentTime() works but Microsoft says it is now obsolete
// and remains only for backward compatibility with 16 bit
// programs. It would only break about a million 16 and 32 bit
// programs if they dropped it but go ahead and use GetTickCount()
// instead of GetCurrentTime() since it works just as well.
//
// MSVC and Borland will allow comments inside the macro but
// both compilers have the same problem when it comes to
// using the 'double-slash' single line comments. Both compilers
// will screw up the macro unless it uses standard ANSI 'C' comment
// style for each separate comment line with the 'line continuation'
// marker at the end.

// Once this new 'exit()' macro has been defined and a thread
// goes to issue an 'exit(99)' command ( or some other exit code )
// this is what will appear on the console...

// ****> exit(99)
// File: .\src\RCTPDW.C
// Line: 197
// Inside exit(99) critical section now...
// The program will terminate in 30 seconds...
// You may press any key during that time and
// the wait loop will terminate early.
//
// Performing real exit(99) now...
//
// V:\RCI\SERVERS\RCTPDW >  <-- Actual exit to OS with error code 99

#undef exit
#define exit(code) \
  InitializeCriticalSection( &g_exit_interceptor_critical_section1 ); \
  EnterCriticalSection( &g_exit_interceptor_critical_section1 ); \
  printf( "****> exit(%d)\n", code ); \
  printf( "File: %s\n",  __FILE__ ); \
  printf( "Line: %ld\n", (long) __LINE__ ); \
  printf( "Inside exit(%d) critical section now...\n", code ); \
  printf( "The program will terminate in 30 seconds...\n" ); \
  printf( "You may press any key during that time and\n" ); \
  printf( "the wait loop will terminate early.\n" ); \
  g_exit_interceptor_startup_time = GetTickCount(); \
  for ( ;; ) \
     { \
      if (kbhit()) break; \
      g_exit_interceptor_current_time = GetTickCount(); \
      g_exit_interceptor_elapsed_time = \
      g_exit_interceptor_current_time - \
      g_exit_interceptor_startup_time; \
      /* Remember that all the times are in milliseconds so */ \
      /* multiply the wait time in seconds by 1000... */ \
      if ( g_exit_interceptor_elapsed_time > (30*1000) ) break; \
     } \
  printf( "\nPerforming real exit(%d) now...\n", code ); \
  /* It isn't even necessary to release the critical section */ \
  /* and, in fact, might be harmful to do so since other threads */ \
  /* will get a few more CPU cycles when the critsec comes off. */ \
  LeaveCriticalSection( &g_exit_interceptor_critical_section1 ); \
  exit( code ); // Return original exit code to OS

#endif // WIN32

* VIEWCVS

( To William Rowe )...

Thanks for providing the VIEWCVS links!

I didn't even know there was such a thing. Pretty neat!

However... the dynamically generated HTML is HUGE and I
thought you should know about something...

There is a way to receive all that HTML into your browser
compressed upwards of 85 percent in real time. You don't
need any sort of 'client' piece to do it... just any version
of MSIE or Netscape or Opera that supports standard IETF
Content-Encoding.

Proxy your browser to 12.17.228.52 port 5010
and ask for the following Apache VIEWCVS document...

http://www.apache.org/websrc/viewcvs.cgi/apache-1.3/src/main/
http_main.c.diff?r1=1.491&r2=1.503

As of this morning (06/17/00) the page was about 105k
worth of HTML.

Going through the proxy server mentioned above it will
load fully in about 4 seconds over a 28.8k modem
connection to the Internet versus upwards of 80 SECONDS
without going through the Online Internet Compression Server.

The Online Internet Compression Server at 12.17.228.52:5010
obtains the page from Apache at T3 speeds, compresses it
dynamically upwards of 85 percent and then sends the highly
reduced version back to your browser over the modem connection.

( No, that's not a typo... since the VIEWCVS pages are
nothing but VERY redundant HTML they are compressed upwards
of EIGHTY-FIVE percent. A typical 90k+ VIEWCVS HTML page
usually come out only around 6 or 8k. That's 80,000+ less
bytes that have to be sent 'over the wire' at all times. )

Going through the Online Internet Compression Server
at 12.17.228.52:5010 is the only thing that makes the
VIEWCVS tolerable here in dial-up land.

I live in the forest on top of a mountain about 40 miles
outside of Little Rock, Arkansas. In the county I live in
there isn't even 1 single traffic light and the only
Internet Access available in the entire county comes from
a guy who lives on a farm near the only Alltel blockhouse
and was able to get a T1 connection and share it over
a couple of old 28.8k modems he had lying around. He
hangs drywall during the day and maintains the routers
in the evening. The routers actually sit on the porch
outside his house in what used to be an old chicken coop.

So 28.8k is the best I can hope for. That's why I wrote
some online Internet Content Compression Servers...
I HAD to... and there are lots of others who now find
them a lifesaver when it comes to dealing with bloated
HTML pages over dial-up connections.

Receiving compressed Internet Content is not a luxury
anymore... it's a necessity for the 80+ percent number
of Internet users who still only have access to low
speed dial-up connections.

Before anyone 'jumps my ass' ( again ) on this forum for
'pushing a product' please realize the following...

1. I am not ASKING you to use it, I'm just telling you
that if you are trying to deal with VIEWCVS over a
dial-up connection without getting all that HTML
compressed you are suffering needlessly.

2. It is FREE. I am not ASKING for anything. Just go
ahead and use that server during your VIEWCVS sessions
( or any other time ). If you remain proxied to it you
will be receiving the entire Internet compressed 80-85%
at all times. If your browser is NOT capable of receiving
standard IETF Content-Encoding then you will be in
'pass-thru' mode and will be receiving pages uncompressed.

3. If you DO use that compression server just remember that
a few thousand other people are using it too and even though
our Servers can handle significantly more transactions
per second than your average Server ( even Apache and even
while compressing everything ) so many people are now relying
on that server that the CPU starts to breathe hard at
certain times... mostly during the morning and early evening.

4. If anyone wants to donate some hosting for additional
copies of the compression server that would be FREE for anyone
to use just drop me a line. It really does help and we have
about exceeded our own ability to handle all the people that
want to use it full time... we are filling the T3 most of
the time now. The compression server is available for pretty
much ANY version of UNIX and ANY version of Windows.

Yours...

Kevin Kiley
CTO, Remote Communications, Inc.
http://www.RemoteCommunications.com
http://www.rctp.com - Online Internet Content Compression Server


Mime
View raw message