QUICK on UNIX - Session Hang after Network Cutoff

[Peter Bateman]

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 TIME 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 there is a much better chance of 
        a  clean update and hence no need to rollback the 
        update  transaction. 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 nor 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 nor 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 attached to the QUICK process.
 
        Indeed as we move forward into the SOX        and CSOX world manual interventions by
        programmers are 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/99cc9297/attachment.html