QUICK on UNIX - Session Hang after Network Cutoff

Peter Bateman peterbateman808 at hotmail.com
Fri Feb 1 14:50:13 CST 2008


Hi Ghani:         Do you have the QKGO TERMINAL TIMEOUT parameter set 
         to a positive number?        I like Bob Mills' solution of keeping the session active        if that what the client wants. This assumes that you        have enough licences to use one up  for each client  all day.         In Bob Mills case you would want the QKGO TERMINAL TIMEOUT
        parameter  to be  zero. i.e. no timeout.                  Some SSH Hosts  automatically time out their clients.          There is another timeout available it is called the         ROLLBACK TIMEOUT. Its purpose is to give        the user time to fix an error that occured while the        update transaction is opened. If the user does not        enter something in the allowed time then a timer exception        is detected and the update transaction is rollbacked.        I like to do foreign key checks and value checks before        attempting the update thus although the database will        also do them as well within the update transaction 
        there is a much better chance of a clean update. I use
        deferred constraint checking as well.                 Some packet based networks drop the connection if a timer
        exception has occurred.
 
        Quick tries to be nice and  gives you a warning that the
        session  is about to timeout. There are two timeouts involved
        timeout 1  to get the warning and timeout 2 for real.
 
        Enhancement:       
          
        1) When an SSH Host automatically times out a client or
         whenever there is an error on stdin or stdout
        I think QUICK  should exit.
                i.e. the same as of you had hit the system exit key
        except no IO attempts on stdin or stdout.
 
        2) Have an option in QKGO and  PHRS
        called KILL_ON_TIMEOUT.  The QUICK process acts as
        if the sytem exit key ( usually control_Z) has been hit
        except no IO attempts on stdin or stdout. e.g. no timeout
        warning.
 
        I have been in situations where I have had to decide to kill 
        QUICK sessions because they appeared to be hung. This is
        not a lot of fun especially when there is a relational database attach 
        to the QUICK process. Indeed as we move forward into the SOX
        and CSOX world manual interventions by programmers is just not  
        allowed. The activities of Jerome Kerviel of he French bank 
        Société Générale will bring application security to an even higher
        focus.
 
 
         
  
                  Good luck,
         Peter Bateman                                     


Date: Thu, 31 Jan 2008 17:30:03 +0800From: abdghani at staroba.orgTo: powerh-l at lists.sowder.comSubject: QUICK on UNIX - Session Hang after Network CutoffDear all,I have a customer who is having problem with QUICK via Reflection remote connection. While QUICK is in session, the connection is lost and quick   processes appear to be continually trying to read() from a pty which has no underlying telnet connection active any longer.  The code path they enter when the pty is in this state causes all to be woken at once. The system has so many 'quick' processes (depending on the number of sites connecting and lost connection) in this state that they are all waking/sleeping together and causing lots of extra CPU time in the scheduling related kernel code paths.Powerhouse Version:  8.43.D1UNIX Version: HP-UX 11.2Appreciate any input.Thanks & regards,Ghani.
_________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20080201/c4a4cb4b/attachment.htm


More information about the powerh-l mailing list