Reporting internal state and errors to plugins

["Alan M. Carroll" <am...@apache.org>]

Based on some discussions here at the summit, we would like to add the ability for the core to report certain error conditions to plugins. We have at least one use case where it is critical to be able to distinguish different causes for a 502 error (origin server down, cache write lock missed, etc.).

The basic concept is the core adds a header to the transaction which reports the error. This lets plugins do special handling without embedding that (or related configuration values) in the core and potentially to log those conditions.

There are two approaches.

The first is to have a single header, @ats-internal, which is used for reporting. This would be a comma list in the standard HTTP header way with each condition code required to be unique. For instance, a cache write lock miss would be "CACHE_WL_MISS" yielding '@ats-internal: CACHE_WL_MISS". This is easier to log but a bit harder to process for different errors (since you have to search the values).

The second is to designate another character as "do not print this header", such as '%', and reserve that for the ATS core. In this case we can use the header namespace without concern for name collisions. The previous case would then be "%cache-doc-error: WRITE_LOCK_FAILED". This is harder to log but easier to detect a specific condition you want to handle.

Any comments are welcome.

Re: Reporting internal state and errors to plugins

[Leif Hedstrom <zw...@apache.org>]

> On Apr 16, 2015, at 5:54 PM, Alan Carroll <so...@yahoo-inc.com.INVALID> wrote:
> 
> A third option is to add an API and data on the HTTP state machine to store the error code. This has the issue that it's harder to have multiple conditions active. On the other hand it's not overloading some other mechanism and would be faster (by comparing number values instead of strings).
> 
> 


I think this has a lot of potential, and we can also add a new log tag that lets you at least “dump” the error codes / state. They don’t have to be pretty, requiring a decoder ring to figure out what the error is in the log for this would be fine IMO (we have other less flexible, but more descriptive error tags already).

— Leif

RE: Reporting internal state and errors to plugins

["Bardwell, William" <wb...@akamai.com>]

I would find something where I can make programmatic decisions based on the general class of error, e.g. "was a client side problem" "was a cache related problem"
"was an origin connection problem" "was a protocol violation" most useful.   While also being able to get the specific error values.  To me that implies an API, although if the strings in special headers were of a standard format that included that sort of info you could get the same results that way.

-William Bardwell

Re: Reporting internal state and errors to plugins

[Alan Carroll <so...@yahoo-inc.com.INVALID>]

A third option is to add an API and data on the HTTP state machine to store the error code. This has the issue that it's harder to have multiple conditions active. On the other hand it's not overloading some other mechanism and would be faster (by comparing number values instead of strings).