QUICK on UNIX - Session Hang after Network Cutoff

[Abd Ghani Abdullah]

   Hi Peter,

   Thanks for the input. The QKGO parameter in this case has been set
to 0. The network connection to some of the remote sites are quite
problematic as most of them are on dial-up and often experience lost
connection.

   As quick is expecting user's input the session in the host will be
active. We also have a daemon process looking for this type of
situation to kill-off quick sessions without terminal connection. It
was working fine previously but the customer is experiencing problem
right now. I suspect it could be due other problem but wanted to
check with this forum if there are elegance way of handling this.

   Regards,

   Ghani.

Quoting Peter Bateman <peterbateman808 at hotmail.com> on Fri, 1 Feb
2008 19:31:48 -0400:

>
>
>
>
>
>
> 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/20080204/7efb9bba/attachment.html