Browse Prior Art Database

Method and system for cognitively preventing a stale or hang state

IP.com Disclosure Number: IPCOM000247796D
Publication Date: 2016-Oct-06
Document File: 4 page(s) / 134K

Publishing Venue

The IP.com Prior Art Database

Abstract

The article dynamically prevents the application from going into hang state by killing the suitable locks cognitively

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 48% of the total text.

Page 01 of 4

Method and system for cognitively preventing a stale or hang state

Multi-threaded Server applications are prone to loosing running state and become unresponsive. Normally we call such applications to be in hang or stale state and sometime this may lead to a situation where application and OS both get crashed.

There are multiple reasons because of which the application may go into the hang state.

- Deadlock -  a situation in which two or more competing actions are each waiting for the 

other to finish, and thus neither ever does 

- A particular thread taking more time to finish the job. May be an infinite loop or some database queries run slower(It leads to Increasing requests to database and runs out of threads)


- Resource - no response from target like some networking device, driver is not responding.
- Hang due to reduction paged memory or its table entries.

- Live Lock - similar to a deadlock, except that the states of the processes involved in the

livelock constantly change with regard to one another, none progressing. Livelock is a special case of resource starvation

Features ‐ 

       1. Tagging locks to "Business" and "Non‐business" locks and assignment of corresponding  weights as per priority to each of the locks.

2. Intelligent resolution of hang state of the system without affecting the core Business  functionality of the system.

3. Cognitively identifying the locks that should be killed to resolve the hang state of the  system.

The article keeps track of all the locks, gets the weights for each of the locks, and then resolves  the hang state of the system by killing the suitable lock.
(a). Weights are assigned based on the priority and importance of the lock in terms of business  and non‐business locks.
(b). Suitable lock(s) would be killed based on the algorithm(below).

Where proposed monitoring thread is configured, the issue mentioned in scenario will come  however monitor thread will start taking action once server application start getting unstable.  Below mentioned algorithm will decide which lock needs to be kicked out based on historical  pattern, priority and weightage. 

As soon as first lock from probable list of locks who are responsible for deadlock is cleaned up ‐  other locks can easily move ahead. Certainly monitor thread will keep track of events and spit  into its own log file for future reference. 

This is a value to application and administrator ‐ that allows to control/prevent hang/deadlock  issues without restart of application ‐ no down time. 

1


Page 02 of 4

Algorithm ‐>  Input: Weights in step2.


1. Creation of normal Locks (L1, L2…, Ln) by threads in the system on its corresponding  resources.


2. Assignment of ...