Browse Prior Art Database

A timed lock to allow future webserver executor threads to fail fast due to a misbehaved backend entity

IP.com Disclosure Number: IPCOM000234700D
Publication Date: 2014-Jan-29
Document File: 3 page(s) / 79K

Publishing Venue

The IP.com Prior Art Database

Abstract

In a REST web services environment, it is common that a single GET/POST/PUT/DELETE call relies on a responsive backend service to provide the data - a database for example. Typically it is trivial to determine if this backend service is working, and there is a defined response time after which a response will fail. In some environments however (such as Systems Management), the backend services (often remote systems being managed) are much less reliable, and can require very long wait times. In a synchronous REST API model, it is important to respond to the client with valid data, but not have multiple requests all blocked on a slow/non-responsive backend entity. This solution addresses some of the downfalls of existing solutions. It allows for sufficiently large timeout values (on the order of many minutes), and does not require all data to be cached (which may not always be possible). It ensures the webserver will continue to remain responsive while providing non-error responses in all but the exception scenario with a misbehaved backend resource.

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

Page 01 of 3

A timed lock to allow future webserver executor threads to fail fast due to a misbehaved backend entity

In a REST web services environment, it is common that a single GET/POST/PUT/DELETE call relies on a responsive backend service to provide the data - a database for example. Typically it is trivial to determine if this backend service is working, and there is a defined response time after which a response will fail.

In some environments however (such as Systems Management), the backend services (often remote systems being managed) are much less reliable, and can require very long wait times. In a synchronous REST API model, it is important to respond to the client with valid data, but not have multiple requests all blocked on a slow/non-responsive backend entity.

In a typical systems management scenario, the REST API needs to return information that can only be obtained from a remote system under management. If said system becomes slow to respond, numerous GET requests may all block on retrieving data from this single slow system. A webserver will only tolerate a certain number of inbound requests before becoming non-responsive to all requests - regardless of whether they block on the non-responsive resource or not. Options for handling this include:

Setting relatively short timeout values. If the system doesn't respond within X seconds, an error of

1.


2.


1.


2.


1.


2.

some form is returned to the user. This is typically how one would handle such a scenario. However, there are times where the slow response is very legitimate, and it is vital that the REST client be able to obtain the data - regardless of the time taken (within reason).

Cache all data - and simply always return cached data. In a systems management environment, the

correctness of the data returned is important as the client will make configuration decisions based on that data - which if incorrect, can result in misconfiguration.

There are two primary ideas behind this invention:

A lock per backend resource which allows the current holding thread to set a timer for how long a

future thread will wait trying to obtain the lock. This differs from a typical Lock which allows the thread attempting to obtain the lock to specify a timeout after which it will give up. In this case, the timeout on obtaining the lock is based on how long the lock has already been held. Once a thread fails to obtain the lock, said thread can fail fast and return to the user in an appropriate manner. This means that if the lock has already been held for its maximum 'acquire wait time', new requests to obtain the lock will fail immediately and not block.

Support for a 'Master Thread' concept which ensures that at least one thread (set as the Master) will

be able to return a complete response to the user where multiple calls to the backed resource are required. This allows for a more granular lock rather than obtaining the lock through multiple calls. Without this, it would be possible that no sin...